Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rethink Release process #2

Open
ccremer opened this issue May 24, 2023 · 0 comments
Open

Rethink Release process #2

ccremer opened this issue May 24, 2023 · 0 comments
Labels
enhancement New feature or request

Comments

@ccremer
Copy link
Contributor

ccremer commented May 24, 2023

Context

Currently, the repo is configured as a Monorepo with tools that are tailored for monorepos:

  • Lerna, for managing package dependencies and build order
  • auto, for releasing packages based on PR labels

auto uses Lerna to discover which packages to release, however, it turns out that auto releases unrelated package versions.
For example, if Package B depends on package A and a PR makes changes only to package B, then both package A and B get a new version as defined via PR label, even though package A hasn't received any changes.

We could consider an alternative release tool stack.
In the past I've made great experience with https://github.com/mikepenz/release-changelog-builder-action/, which also categorizes PRs into categories identified by PR labels. However, we'd need additional logic to figure out:

  • what is the "highest ranking" category that PRs were labelled with for a certain package since last release
  • Release only the affected packages that received release-triggering labels
  • Bump the version and commit to main branch

Out of Scope

  • conventional commits (we'll stick with PR-label-based workflows)

Further links

No response

Acceptance Criteria

Given a PR with label `minor`
And the PR contains changes made for package A
And package B depends on package A
When the PR is merged
Then package A is released with a new minor version number
And package B stays on the current version number
Given a PR with label `minor`
And the PR contains changes made for package B
And package B depends on package A
When the PR is merged
Then package B is released with a new minor version number
And package A stays on the current version number
Given a PR with label `canary`
And the PR contains changes made for package A
And package B depends on package A
When the PR receives new pushes
Then package A is released with a canary version number

Implementation Ideas

No response

@ccremer ccremer added the enhancement New feature or request label May 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Development

No branches or pull requests

1 participant