thombruce / verse

🚀 A universe in progress
Other
8 stars 0 forks source link

Add CI Test Build #82

Closed thombruce closed 9 months ago

thombruce commented 10 months ago

v0.0.20 was undeliverable due to an oversight and the omission of a dependency required by the production build.

This is patched as of v0.0.21, but ideally we would catch this in automated testing.

Consider adding a test build to the GitHub Actions schedule that runs more frequently than the release builds do (these run on tagged releases).

How frequently? Should they run on every push to main? We could skip when it isn't relevant with --skip-ci or whatever the commit message format is.

I don't mind too much if patch versions are omitted like this, but I would like to avoid major and minor versions facing this problem.

thombruce commented 10 months ago

When should we test?

That's... pretty much every push.

There's an argument to be made that any new PR changes could also bump the minor version; that way, every main test would also be a main build, because we'd no longer being doing arbitrary increments...

Alternatively, we could adopt a different Git Flow, perhaps introducing a development branch and versioned releases. If so, nominate main as the dev branch; I'd like main to remain the leading state of development.

Eventually we might have a more complicated git flow where changes are merged regularly into main, but not all of those changes will make it into the next production release... 🤔 This sounds kind of complicated to manage. Branches would need to be tracked appropriately. Merged to main and then... later also merged to a production branch when they're tagged for release. I'd prefer to keep the development flow simpler, honestly.

We can do the exact same thing more "simply" (more familiarly anyway) by having main not be the leading dev branch. Instead, we'd merge changes to a dev branch and only close and merge PRs to main when they're ready for a production release. There could be many dev branches ("supers") representing a desired new state for production; think like, a "v0.1" branch. Just an idea. We should plan for something like this eventually. But for now, we're just talking... when do we test? Where do we test?

[^1]: Presently I don't upgrade versions as PRs, so the versioned builds will still skip this unless I change practices.

Brandon-Huu commented 9 months ago

When should we test?

* [ ]  PRs should be tested before merging

I think this is a great thing to do. It's what https://github.com/space-wizards/space-station-14/ does.

Github does all of the CI for free so I don't see any reason not to do it.