Adding nightly builds to engine?

Development
21

In case anyone’s unaware:

Every commit to GitHub triggers an Actions run that, if successful, produces a “maven.zip” artifact containing all the library POMs and JARs. For instance:

These artifacts are retained for many months or until explicitly deleted.

1 Like
22

True. However, that’s not particularly helpful for users that want to pull a snapshot into their existing builds for testing; hence the effort to upload to a snapshot repository.

We could, but that’s going to duplicate all of the build setup configuration unless we refactor the process. A job in the existing workflow can use the existing builds. I’m not sure that the double-build thing will create a real-world issue. How often would you expect to merge 2 or more PRs less than, say, 5 minutes apart?

23

Without putting words in his mouth, I believe sgold’s point was that the “build” part is already done and only the “deploy” part would be necessary.

…and I guess there may be an existing action to hook too if that’s even possible.

24

This is the approach I’ve taken so far.

EDIT: if you and @sgold are implying that a separate scheduled workflow could go back and grab the artifact from the most recent workflow run, it probably could. That feels rather duct-tape and Baling Wire to me.

25

Without putting words in either Paul’s or Stephen’s mouth, what I believe they are saying is to simply publish at the end of a build on the master branch. Many large projects already do this without any issues. We already perform a full build, it simply needs to be uploaded to the maven central snapshot repo after a build on the master branch.

26

It happened several times already, we can try it, maybe this wont be an issue like you said or else we can merge them with some delay, not a big deal.

By the way, doesn’t publishMavenPublicationToOSSRHRepository and publishMavenPublicationToSNAPSHOTRepository already build the artifacts from the source?

I believe they do, ignoring the pre-built artifacts in the previous job, based on the recent issue we had main.yml: OSSRH artifacts are build with different java version · Issue #1923 · jMonkeyEngine/jmonkeyengine · GitHub

27

… I believe that you are correct. I was mislead by the fact that the DeployRelease job also retrieves the existing builds from the testing runs. (Those retrievals would be superfluous, and should probably be removed from the workflow definition. EDIT: Except, we are using the pre-build artifact for the Github release asset.)

This actually means that scheduled runs for the snapshots would be rather simpler than I had thought - they could go in their own workflow, and not depend on the test builds. (it does, however, mean that we might end up with a deployed snapshot that has a broken build or set of tests - unless we also deliberately run the test suite in the snapshot workflow.)

==========================

Side rant/note:

I think that we’ve got these two sort of parallel, not-quite-redundant ways of looking at build artifacts because no one knows exactly how the build scripts work. They aren’t documented - at least not in any location that I’ve been able to find - and are very hard to follow. (The later is at least partly due to gradle using a DSL that appears to be designed for code-golf, not for clearly specifying how components are built for the benefit of the developer who needs to tweak the build once every few months.)

Any cleanup effort there - which might spiral into a rather large project - would have to consider whether it is desirable to build and upload the maven artifacts through the gradle interface, or directly in the Actions definition. (both are possible - in theory)

1 Like
28

JME snapshots are now available on

https://s01.oss.sonatype.org/content/repositories/snapshots/org/jmonkeyengine

Thanks so much, @sailsman63 :+1:

Edit:

For using snapshot version add

repositories {
         maven {url 'https://s01.oss.sonatype.org/content/repositories/snapshots/'}
}

and use 3.7.0-SNAPSHOT for jme version. For example:

implementation "org.jmonkeyengine:jme3-core:3.7.0-SNAPSHOT"
5 Likes
29

Note, by default, Gradle will cache changing dependencies (e.g. SNAPHOST dependencies) for 24 hours. During that time, it will not ask the repository for newer versions. So if you publish a new version under the same name, Gradle might not see it for another day.

You can however change caching duration, for example

configurations.all {
   resolutionStrategy.cacheChangingModulesFor 0, 'seconds'
}

See:

https://docs.gradle.org/current/userguide/dynamic_versions.html

3 Likes
30

Thank you :))

1 Like
31

I’ve just opened

to document this on the wiki.

2 Likes
32

Thanks, merged it.

1 Like