search

H-uru / Plasma

Cyan Worlds's Plasma game engine
http://h-uru.github.io/Plasma/
GNU General Public License v3.0
205 stars 81 forks source link

Publish build artifacts to a "last successful build" prerelease after each merge #1417

Closed dpogue closed 8 months ago

dpogue commented 1 year ago

Currently, we have a CI system that runs on every pull request and on every merge to master. It builds Windows 32-bit clients, Windows 64-bit clients, a whole bunch of 3DS Max plugins, and a subset of tools for macOS and Linux. These are attached to the GitHub Actions build results as build artifacts and can be downloaded.

However, these are only available to download to people who are logged in to GitHub, and it's a bit difficult to know where to go to find them (click on Actions, find the right run of the CI workflow, click into it, scroll down in a page with multiple scrollable areas, etc.)

A more user-friendly option would be to publish these build artifacts to a release on GitHub that would be featured on the main repository page and would allow downloads from anyone without requiring a GitHub login. We probably don't want to create a new release for every merge though, so a continuously-updated "last successful build" pre-release is likely the best option.

Hoikas has set up publishing of artifacts to releases as part of the korman workflows, and I've done some similar stuff for projects at work.

Deledrius commented 1 year ago

I've seen a few projects do something similar, and I think it'd be great to have here, especially for the tools (such as the plugins).

dpogue commented 1 year ago

So the downside here is that a GitHub release needs to be associated with a git tag. We could just pick a random commit, make a tag there, and then keep overwriting the artifacts on the release associated with that tag, but that means the date of the release would never update.

Alternatively, we create and delete a prerelease tag every time, but that's kinda equivalent to rewriting history and I've seen that cause issues for people if they try to push and their local copy of the tag doesn't match the upstream copy of the tag.

Maybe the first option is fine for now, since we don't actually have any other releases or tags, and we can overwrite the tag release notes with something that includes the date?

dpogue commented 1 year ago

You can find these build artifacts at https://github.com/H-uru/Plasma/releases/tag/last-successful now :)

dgelessus commented 1 year ago

Just noticed that the current last-successful release doesn't have any artifacts, even though the most recent build supposedly uploaded them... I don't know if this happened before or if it's a one-off issue. Worth keeping an eye on probably.

dpogue commented 1 year ago

There's a bug in this that seems to be marking new releases as drafts, rather than pre-releases. So it deletes the previous release, but then never publicly publishes the new one (and then we end up with multiple drafts). This didn't happen when I was testing out the workflow in my fork, so I'm not sure what's going wrong here 😞

dgelessus commented 1 year ago

Looks like it's working again after the latest change (#1471)!

dpogue commented 1 year ago

I manually cleaned up all the old releases before merging that, so I think we'll need one more build to happen to confirm that it's actually working 😅

dpogue commented 1 year ago

This is almost working... we're only getting one release now (which is what we want) but it's getting marked as a draft instead of a prerelease (which means it's not visible to anyone without write access) 😞

dpogue commented 8 months ago

We refactored this and it seems to be working, https://github.com/H-uru/Plasma/releases/tag/last-successful should always have the results from the latest successful build on master.