I think it might be a good idea to add snapshot (also known as nightly or early access) builds to the engine. So by every commit into the master branch, it can build and publish snapshot artifacts to either the GitHub package or maven.
So for example when some user reports a bug and we fix it and require the user to test out the fix they won’t need to clone and build the engine themselves or wait for the next release. IMO this could be a great help to the development team.
Currently our GitHub workflow script does already build the engine on every commit to the master branch. I think we just need to find out how to publish these artifacts to GitHub packages
As you mentioned in your post, it has a different group id because they are not official releases. I think if we can make this work with Github packages or maven snapshots (like lwjgl3 does) it would be better.
I agree. I just bring it up because they are immediately available until a better solution is built. When I was doing heavy JME work I almost exclusively used the snapshots since we went so long between releases
I have no idea how this get done but it must not be hard work, there is many porjects that do this base on some search i done:
To create nightly releases with GitHub Actions, you need to:
Create a workflow file in your repository under .github/workflows folder
Use the on.schedule trigger to specify when you want the workflow to run (e.g. every day at midnight)
Use the actions/upload-artifact action to attach your build artifact (e.g. a jar) to the workflow run
Use the actions/create-release action to create a release from the artifact and give it a name (e.g. nightly-${{ github.sha }})
Optionally, use some conditions or logic to skip the workflow if there are no new commits since the last run
How automated does this need to be, and how often does there need to be a snapshot? There’s a fairly wide swath:
“Need a snapshot for every commit to master”
“Once a day if there are new commits”
“Core devs feel that making this one a little more accessible is worthwhile”
If the preference is for the bottom of the list, the dev who wants to make a snapshot just needs to use the GH UI to create a release targeting master, and use a reasonable tag-name. (due to the way maven coordinates and semantic version numbers work, it’ll probably be of the format <next-version>-YYYY-MM-DD-SNAPSHOT.)
For the other options, it’s not too hard to get github actions to create a release when certain criteria are met.
In either case, we’d be leveraging the existing deployment mechanism.
Sometimes it happens that we merge a bunch of PRs at once, could this be a problem with this approach?
if so then the next option (“Once a day if there are new commits”) sounds nice.
I looked at lwjgl3 build config
it sounds like the difference between release and snapshot is in the Sonatype repo URL.
I am curious if it needs manual staging (manually closing and releasing repo) that we do for releases from the Nexus Repository Manager?
Do the new snapshot artifacts automatically overwrite the previous ones on maven?
I think we do not need to keep different versions of snapshot releases so probably YYYY-MM-DD is not needed for snapshot releases. It should be <master-version>-SNAPSHOT for example 3.7.0-SNAPSHOT
I am using the lwjgl3 3.3.2-SNAPSHOT version and I noticed whenever a new 3.3.2 snapshot is released gradle automatically downloads and replaces the old snapshot.
That could be a downside - You’ll get however x-many deploys in quick succession. The downside to “Once a day” is that if you’re trying to deploy a change so that downstream users can test it, you’re looking at up to 24 hours before they can see it.
I didn’t realize that Sonatype has a separate repository for Snapshots. That means that
is a “No!”. A user that wants to grab the snapshot will have to add maven { url "https://oss.sonatype.org/content/repositories/snapshots/" } to their repositories list in their build script, which I think is fine. (these snapshots then would never make it onto maven central.) The only people who should be using snapshots are those who understand how to opt into them.
I agree if we’re okay with only supporting snapshot builds through maven style dependency-management clients. (Includes gradle, ivy, mill, etc.) If snapshots need to have a zip file on a github releases entry, we need the timestamped builds, as github doesn’t handle re-using release names very well.
The “SNAPSHOT” suffix tells the build system that this particular dependency should be re-checked on every build.
If the sonatype-only deploy option is okay, I actually would actually recommend going with “Snapshot every commit to master,” and I now think I have enough info to implement it. If this sounds good to the team, I can run up a PR.
Hmm… Just did a little spot test. That might well be a concern, since the two runs seem to function in parallel, with no guarantee that they’ll finish in strict order.
What about “Every 6 hours if there are new commits to master”?
Edit:
Seems someone already created an action that checks if there has been any new commit in a given time frame
we can create a new workflow and schedule it to run every 6 hours and check if there are new commits using the above action and then build the snapshot.
// new workflow
name: Build & deploy snapshots
on:
schedule:
- cron: '0 */6 * * *' // run every 6 hours
