🛤️ tracking: Release Automation

[runspired]

The EmberData team recently landed a number of improvements to the release publishing and CI pipelines to reduce the cost overhead of releases, enable publishing canary builds to npm, and prepare for a more automated future.

This ticket outlines remaining work items we hope to accomplish to complete our quest for low-to-zero-overhead releases:

CI

• [x] ensure we match Travis for current Azure setup 🔒Claimed by @HeroicEric https://github.com/emberjs/data/pull/6098
• [x] Drop travis.yml and deactivate Travis for ember-data We dropped all jobs we could. Once we have allowed-failure equivalent in gh-actions we will drop the rest.
• [x] validate that all PRs have a label for the targeted branch
• [x] validate that all PRs have a label for their kind (fix|chore|test|security etc.)

Branch Management

• [ ] document how to use the backporting bot feature for backporting fixes to beta and release branches
• [ ] improve backporting bot feature to account for fixes that need to target both beta and release branches
• [ ] configure the backporting bot to work via labels
• [ ] [DISCUSS] backporting bot should run lint --fix automatically on backported commits

Changelog Generation

• [x] move to lerna changelog from custom solution
• [x] add changelog generation into the lerna version automation step in our release script
• [ ] investigate configuring our monorepo to publish release notes (possible if using lerna changelog)
• [x] Improve Changelog generated output (ref https://github.com/emberjs/data/issues/7928)
  • don't include beta/canary builds
  • don't include references to private/unpublished packages

Publishing

• [x] Automate nightly publishing of canary to npm registry
  • [ ] failed & successful attempts should notify @core-data in #dev-ember-data on discord
  • [x] should only publish if changes exist since last canary
• [x] configure CI with a token to be used in place of OTP for publishing to npm
• [x] upgrade release script to confirm or bypass the lerna version prompt for the intended version bump

Testing Automation also means we will want to ensure more robust testing.

• [ ] add tests for our automated release process (likely via https://verdaccio.org/)
• [x] IE11 integration tests #6431
• [x] fastboot integration tests #6431
• [ ] make it clear upstream needs to be set
• [x] lts release bumps patch version when it's just a "new channel", is this necessary?
• [ ] update guidance for using lerna-changelog always, not just lts
• [ ] lerna-changelog generates for every alpha, this is annoying, can we auto-collapse to minor/major?
• [x] should we drop internal/house commits?
• [x] we should update azure-pipelines ember-try guidance to reference github actions
• [ ] can we automate the changelog step further?
• [ ] can we auto publish release notes?

[runspired]

cc @HeroicEric for assignment

[BryanCrotaz]

I looked at whether I could contribute on backport bot but it appears to backport onto branches - There are no release branches since 3.4 - is this a change of branching methodology?

[runspired]

@BryanCrotaz we only create specific release branch if we have something to backport, so the first backport we create a branch from the tag.

[runspired]

@BryanCrotaz would you be interested in picking up where @Gaurav0 left off with the backport bot?

[runspired]

with #9231 I don't think this particular ticket serves us much use anymore. I would love for use to get a backport bot still, but automating releases is itself a big enough win I'm not sure its worth keeping this open.