Change release process to facilitate release notes previews #2264
Labels
🤖 aspect: dx
Concerns developers' experience with the codebase
🧰 goal: internal improvement
Improvement that benefits maintainers, not users
🟨 priority: medium
Not blocking but should be addressed soon
🧱 stack: mgmt
Related to repo management and automations
Problem
The current release process makes it extremely difficult to know whether a particular app actually has changes to release. This means we're liable to run the API or frontend release workflow (which we try to do weekly, if there are changes) when there are no relevant changes, resulting in an empty changelog.
Description
To fix this, we need to change the way we use release drafter and the way we trigger releases for particular apps. Rather than using the Release app workflow, we'll configure release drafter to actively draft releases for all our apps whenever changes appear for them. We can use the exact same release drafter configurations we currently have adapted to the old "draft release" workflow. The only caveat is that we need to provide release drafter with the version string because it only supports semver, which we do not use. When these individual releases are published, that will trigger the docker tag creation, the changelog PR, and the production deployment (for frontend and API). The app and datever tag need to be parsed from the release name.
Solution
Create a new workflow called "Draft releases" with a matrix for each of the four apps that can be released (api, ingestion server, frontend, catalog). This workflow should run on pushes to main. Create the date tag and then for each app, run release drafter with the current configurations for each app.
Create a new workflow called "Release" that runs on release publish. This workflow must parse the app and datever string from the release name, tag the appropriate docker images with the release tag (as Release app does now), create the changelog PR based on the published release's text, and then trigger the API or frontend production deployments when applicable.
Afterwards, delete the release app workflow from the GitHub actions UI to remove clutter.
The text was updated successfully, but these errors were encountered: