Adding nightly builds to engine?

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.

Any thought?

Also anyone willing to help with this?


This is a great idea!

I am willing to help but I will be out of town for the last part of March.
I will be available in April if I can do anything then.

I am very new to this platform so I might have a steep learning curve but I am willing to learn.

1 Like


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 :slightly_smiling_face:

Back in 2020 they were on jitpack, are those no longer valid/updated?

Idk, but does jitpack instantly build the snapshot? I thought it takes days/weeks?

Iirc when I used it in the past is was always up to date. I believe it just uses the results from the GitHub actions. Your latest commit is there.

1 Like

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.

1 Like

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


Lwjgl3 is open source so we should be able to find out how they are doing it.

LWJGL has a very complex ci pipeline with a lot of interaction between ant and Gradle, with the GitHub actions housed in their own repo.

You may want to find a simpler example.

1 Like

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.

1 Like

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 "" } 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.


Yeah, that is the intention.
There wont be github releases entry for snapshot release.

Yeah, it sounds good enough. :slightly_smiling_face:
A PR is much appreciated, thank you! :heart:


Is up. Feedback would be appreciated.

1 Like

Thank you so much!
It looks good to me.

So what happens if we merge 2 or more PRs at once?
Do we need to take care to not to do that, or is it fine?

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.

1 Like

What about “Every 6 hours if there are new commits to master”?

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
    - cron: '0 */6 * * *'  // run every 6 hours