Feature: Define the tag policy and enforce deployment triggers if the required tags are not present. #6098
Description
🔖 Feature description
We need to enhance the Tag Policy feature to allow the definition of a set of tags that should propagate to underlying Kubernetes resources such as services, ingresses, pods, etc. If an application does not include the defined tags as per the policy for the dev/prod environments, the system should block the trigger or give warn.
Additionally, we need to provide users the flexibility to define tag values in the following format
| Tag Key (all smalls) | Free vs Fixed | Tag Value Examples (all smalls) |
|---|---|---|
| team | FIXED | hq|bird|infacility|data-dev|odx-services|fms|dwh|mts|ucp|starfleet|thunderbolt |
| app_name | FREE | |
| component | FREE | search, tracker, appcache, etc |
| function | FREE | |
| business_unit | FIXED | Transportation|Fulfillment| ClientApplication | ConsumerApplication | International|Data-Dev |
| environment | FREE | Namespace Name |
| owner | FREE | |
| alerts | FREE | |
| tier | FIXED | [ t0 | t1 | t2 | t3] |
Regarding the environment tag, we currently use envId: xyz. However, we also want to include environment: env-name for better clarity and usability
🎤 Pitch / Usecases
NA
🔄️ Alternative
No response
👀 Have you spent some time to check if this issue has been raised before?
- I checked and didn't find similar issue
🏢 Have you read the Code of Conduct?
- I have read the Code of Conduct