Skip to content

Contribution Process

Jump to bottom
Sino Kholkhojaev edited this page Mar 24, 2026 · 3 revisions

Getting your code to production

The full lifecycle of a Milo PR follows this path:

Phase 1 — Development

  1. Create a feature branch off stage.
  2. Open a PR targeting stage.
  3. Link the Jira ticket in the PR description: Resolves: [MWPW-NUMBER] (jira-url).
  4. Follow the 1 PR = 1 Jira = 1 Issue rule. Keep scope small.

Phase 2 — Review & Approval

  1. Ensure all GitHub checks pass before requesting review:
  2. Unit tests — all Unit tests must pass
  3. ESLint — no linting errors on changed .js files
  4. Code compatibility — browser compatibility check
  5. Adobe CLA — you must be part of the adobecom org
  6. Get 2 developer approvals (binding approvals come from Milo Admins).
  7. Assign/Ask QE for testing. (if you do not have any QE in your team please ask in the #milo-dev for help in verifying)

Phase 3 — Ready for Stage

After gathering approvals from the devs, passing checks, and QE testing and then applying Ready for Stage label, the PR then enters the automated merge queue (see Automated Merge Pipeline).

The automated merge queue runs every 4 hours and squash-merges eligible PRs into stage.

Note: The "queue" is not obvious, but you can investigate the most recent workflow runs to see why your PR was merged or not. If still unsure, reach out to #milo-dev

Phase 4 — Stage to Main (Production)

  1. When PRs are merged to stage, a [Release] Stage to Main PR is automatically created.
  2. SOT (Sign-Off Testing) teams test on stage and apply their SOT labels, which means the Stage is ready to be merged to main without breaking producgtion.
  3. Once 4 or more SOT sign-offs are present and checks pass, the automation merges stage to main.
  4. This only happens during working hours (Mon–Thu, 08:00–20:00 UTC). No Friday/weekend merges.
  5. After merge, the CDN cache (Akamai) is cleared automatically.

Merge Permissions (Roles and where they an merge to)

Contributor: Can submit PRs from forks Committer: Can merge approved PRs to feature branches (not stage or main) Admin: Can merge approved PRs to stage and main Automation: Merges to stage (every 4h) and main (daily, Mon–Thu)

Note: Only Milo Admins and the automated pipeline can merge to stage and main. Regular committers cannot bypass this.

Emergencies

in case of any emergencies or exceptions, see the separate CSO docs

PR Labels - Full Reference

OPerational Labels (Drive Automation)

Label Applied by Purpose
Ready for Stage QE (after approvals + testing) Queues the PR for the next automated stage merge batch. Also exempts the PR from the stale-PR bot.
high-priority Developer Pushes the PR to the top of the stage merge queue, ahead of normal PRs. Use only when the corresponding Jira ticket is a Blocker or Critical.
zero-impact Auto-applied by GitHub Action Applied when a PR only touches non-production files (.github/, tests, configs, CODEOWNERS, nala/, libs/mep/). Zero-impact PRs do not count toward the batch limit. Automatically removed if non-zero-impact files are added.
high-impact Developer Triggers Slack alerts in community and changelog channels. Use for PRs that need broader stakeholder awareness (consumers, GWP, design)
Stale Auto-applied after 7 days of inactivity PR is closed after 7 more days if still inactive. PRs with Ready for Stage are exempt.
run-nala Developer Triggers the Nala E2E test automation suite.

When opening a PR only do so when teh PR is ready to be merged, otherwise for testing/drafts please do so in your forked repository.

SOT (Sign-Off Testing) Labels

Applied by each SOT team after testing on stage. 4 of these are required before stage merges to main

Clone this wiki locally