open5e/open5e-api

Create a github releases repeatable process

Closed this issue · 6 comments

augustjohnson commented

We should leverage the github releases feature. We've already started a bit, but we need to make it consistent.
I think that every push to staging should be versioned, using semver, major.minor.merge. A manual process can be triggered to create a release object based on this (ideally one button).

Release contents:

Entire codebase as a zip.

Bonus: We could convert all the /data into csvs! Shouldn't be too hard, just a basic python script, and a zip. Lots of downstreams just want to load the data once (for example a phone app).

coderatul commented

maybe we could leverage github actions for this purpose i have some experience with github actions could you assign this issue to me

augustjohnson commented

We are using github actions today, so this would be a natural extension of that. Take a look! Let me know if/when you want to review, and if you're not in the discord, I hang out in #dev-api there.

coderatul commented

i have tried a workflow : #421
changes are triggered with commit messages specifying semantic versioning

eg : v1.2.3:"commit message"

augustjohnson commented

I'm having some issues with this overall, I'm thinking we abandon this approach for now. Let's back this out when we get a chance. Leaving this open for the effort to delete the github action.

https://github.com/open5e/open5e-api/actions/runs/8661644421/job/23751994534

augustjohnson commented

Here's the ideal flow:
[ x ] Only maintainers can merge into the default branch (staging).
[ x ] A merge into staging results in a deploy to the api-beta environment.
[ x ] Only maintainers can merge into the production branch (main).

Upon merge to main:
[ ] A build occurs, a deploy is prepared, but not committed.
[ ] A button is surfaced, clickable only to maintainers that does the following items.
[ ] Upon clicking that button, and entering in a Release name or tag:
[ ] A git tag is created that matches a standardized format.
[ ] A release draft is created (default content).
[ ] Deploy is run.

If the maintainers DON'T click the button, no release occurs.

augustjohnson commented

Closing this, the manual process seems to work effectively.