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.