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

Change release process to facilitate release notes previews #2264

Closed
sarayourfriend opened this issue Jun 1, 2023 · 1 comment · Fixed by #3755
Closed

Change release process to facilitate release notes previews #2264

sarayourfriend opened this issue Jun 1, 2023 · 1 comment · Fixed by #3755
Assignees
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

Comments

@sarayourfriend
Copy link
Collaborator

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.

@sarayourfriend sarayourfriend added 🟨 priority: medium Not blocking but should be addressed soon 🤖 aspect: dx Concerns developers' experience with the codebase 🧰 goal: internal improvement Improvement that benefits maintainers, not users 🧱 stack: mgmt Related to repo management and automations labels Jun 1, 2023
@github-project-automation github-project-automation bot moved this to 📋 Backlog in Openverse Backlog Jun 1, 2023
@stacimc stacimc self-assigned this Oct 17, 2023
@stacimc stacimc moved this from 📋 Backlog to 🏗 In progress in Openverse Backlog Oct 20, 2023
@stacimc stacimc moved this from 🏗 In Progress to 📅 To Do in Openverse Backlog Nov 28, 2023
@stacimc stacimc removed their assignment Feb 2, 2024
@stacimc
Copy link
Collaborator

stacimc commented Feb 2, 2024

Unassigning myself as I have been unable to get around to this and don't want to continue blocking the work. I may pick it up again but anyone else who'd like to grab it should feel free.

@sarayourfriend sarayourfriend self-assigned this Feb 6, 2024
@sarayourfriend sarayourfriend moved this from 📅 To Do to 🏗 In Progress in Openverse Backlog Feb 6, 2024
@openverse-bot openverse-bot moved this from 🏗 In Progress to ✅ Done in Openverse Backlog Feb 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

2 participants