Skip to content

LABELING_GUIDELINES.md

Latest commit

 

History

History
56 lines (32 loc) · 4.04 KB

LABELING_GUIDELINES.md

File metadata and controls

56 lines (32 loc) · 4.04 KB

PR Labeling Guidelines

To maintain a consistent and efficient development workflow, we have set specific label guidelines for all pull requests (PRs). Please ensure you adhere to the following instructions:

Mandatory team label (automated)

  • Internal Developers: Every PR raised by an internal developer must include a label prefixed with team- (e.g., team-mobile-ux, team-mobile-platform, etc.). This indicates the respective internal team responsible for the PR.

  • External Contributors: PRs submitted by contributors who are not part of the organization will be automatically labeled with external-contributor.

Mandatory checklog entry or label (manual addition)

The releases changelog generation is based on PR's changelog entries. The check can be bypassed when necessary, either by setting the changelog entry to "null" or by adding following label:

  • no-changelog: PR's changes do not need to be included in the changelog.

Automated labels (applied by CI)

E2E readiness gate

  • pr-not-ready-for-e2e: Automatically applied to every newly opened PR. While present, E2E build and test jobs are skipped. Merge is also blocked — unless all changes are ignorable-only. For PRs with non-ignorable changes, the PR owner must remove this label when the PR is ready for E2E validation; once removed, CI re-runs and E2E tests execute normally.

For the full CI flow that these labels control, see E2E_DECISION_TREE.md.

Optional labels (manual addition)

Any label can be manually added on demand depending on the PR's content. For instance, the label QA passed will indicate that a thorough manual testing has been performed and the PR is ready to be merged. In addition, following labels have some specific use cases.

Bypass Quality Gates

Using any of these labels should be exceptional in case of CI friction and urgencies. Please use them reasonably and verify new changes and regressions manually.

  • skip-sonar-cloud: The PR will be merged without running SonarCloud checks.
  • skip-e2e: The PR will be merged without running E2E tests.
  • skip-e2e-quality-gate: This label will disable the default test retries for E2E test files modified in a PR. Useful when making large refactors or when changes don't pose flakiness risk.

Skip Smart E2E Selection

  • skip-smart-e2e-selection: Bypasses the AI-powered Smart E2E Selection so that the full E2E test suite runs instead of an AI-picked subset. This label does not force E2E builds/tests to run on a PR that would otherwise skip them (e.g. docs-only changes). Whether E2E runs at all is determined by path filters, branch, and other skip labels — not this label.

Block merge if any is present

  • needs-qa: The PR requires a full manual QA prior to being merged and added to a release.
  • need-ux-ds-review: The PR requires a review from the User Experience or Design System teams.
  • blocked: There are unresolved dependencies or other issues blocking the progress of this PR.
  • stale: The PR has not had recent activity in the last 90 days. It will be closed in 7 days.
  • DO-NOT-MERGE: The PR should not be merged under any circumstances.

Release version label (automated)

  • release-x.y.z: This label is automatically added to a PR and its linked issues upon the PR's merge. The x.y.z in the label represents the version in which the changes from the PR will be included. This label is auto-generated by a GitHub action, which determines the version by incrementing the minor version number from the most recent release. Manual intervention is only required in specific cases. For instance, if a merged PR is cherry-picked into a release branch, typically done to address Release Candidate (RC) bugs, the label would need to be manually updated to reflect the correct version.

To maintain code quality and project integrity, it's crucial to respect these label guidelines. Please ensure you review and update labels appropriately throughout the PR lifecycle.

Thank you for your cooperation!