Promotion pr labels

[bitte-ein-bit]

Description

This pull request introduces support for specifying custom labels for individual promotion PRs in the configuration, and ensures these labels are merged with top-level promotion PR labels without duplicates. The changes update the configuration schema, documentation, and implementation, and add comprehensive tests for the label merging logic.

Configuration and Documentation Updates

• Added a new labels field to the promotionPrs configuration, allowing users to specify custom labels for each promotion PR. The documentation (docs/installation.md) and schema (schema/telefonistka.json) were updated to reflect this change. [1] [2]
• Renamed the top-level configuration key from promtionPRlables to promotionPrLabels for clarity and consistency in docs, schema, and code. [1] [2] [3]

Implementation Changes

• Updated the PromotionPr struct to include the new Labels field, and ensured it is passed through the promotion planning logic. [1] [2] [3]
• Added a mergeLabels function to deduplicate and merge top-level and PR-specific labels, and integrated it into the PR creation flow. The createPrObject function now accepts a labels parameter and applies merged labels to PRs. [1] [2] [3] [4]

Testing

• Added and updated unit tests to verify correct parsing of the new configuration options and the label merging logic, including edge cases for duplicate and overlapping labels. [1] [2] [3] [4] [5] [6]

These changes make promotion PR labeling more flexible and robust, improving both configuration clarity and downstream automation.

Type of Change

• Bug Fix
• New Feature
• Breaking Change
• Refactor
• Documentation
• Other (please describe)

Checklist

• I have read the contributing guidelines
• Existing issues have been referenced (where applicable)
• I have verified this change is not present in other open pull requests
• Functionality is documented
• All code style checks pass
• New code contribution is covered by automated tests
• All new and existing tests pass

[Freyert]

@bitte-ein-bit could you share some "value scenarios" or "business impact" here? I imagine this might allow you to propagate important labels from the root PR to the children?

Will this help for example find all promotions related to a security label?

[bitte-ein-bit]

@Freyert sure. We use Terragrunt's new stack feature. That means we have roughly this (over simplified) filesystem layout in our IaC repository@

• dry
  • product1
    • dev
    • prod
  • product2
    • dev
    • prod
• hydrated
  • product1
    • dev
    • prod
  • product2
    • dev
    • prod
• live
  • product1
    • dev
    • prod
  • product2
    • dev
    • prod

dry -> hydrated is done using terragrunt stack generate and some copy foo.
hydrated to live should be done by telefonistka.

Each product needs to be updated individually. This works fine when a human is developing things. But e.g. Mend's Renovate will update the catalog version in dry in one shot across all products. Afterwards we need to fan out into separate PRs per product and ensure that prod is never merged before dev.

The issue is with the order requirement. Without this feature, figuring out the order was a mere hit-or-miss approach. With this feature, I can run this config:

promotionPaths:
  - sourcePath: "hydrated/[^/]+/[^/]+/"
    conditions:
      autoMerge: false
    promotionPrs:
      - targetPaths:
        - "live/product1/dev/"
        labels:
          - "dev"
          - "product1"
      - targetPaths:
        - "live/product1/prod/"
        labels:
          - "prod"
          - "product1"
      - targetPaths:
        - "live/product2/dev/"
        labels:
          - "dev"
          - "product2"
      - targetPaths:
        - "live/product2/prod/"
        labels:
          - "prod"
          - "product2"

promotionPrLabels:
  - "promotion"

The resulting PRs are labeled accordingly. So one out our Jobs checks the labels, checks which PR is the parent one and checks if any siblings need to be merged first according to our ruleset. If so, it will fail the job and thus block the merge.

[bitte-ein-bit]

@Freyert any updates or further questions?

[bitte-ein-bit]

I've ditched telefonistka because of too many issues. I won't follow up with this PR anymore. Feel free to keep it or dismiss it.