Nightly Build is now established

Development
1

We have now a Nightly Build. This will perform a ./mvnw clean install without Maven Cache to make sure that everything builds from scratch.

Bildschirmfoto 2024-11-26 um 09.49.05

Additionally it will produce some code reports, e.g. the build plan, LOC metrics, update analysis and attach this in a “reports” zip.

And it provides the distros as downloadable attachments.

This is a first approach. If you have ideas how we can improve this then open issues. My ideas are:

  • provide the distros in a way that the latest is always available via a link that could be referenced from the README
  • build more distros via matrix builds

Bildschirmfoto 2024-11-26 um 09.49.44
Bildschirmfoto 2024-11-26 um 09.49.441318×1171 136 KB

4 Likes
2

Looks great, thanks! I have thought about some things, which do not necessarily need to go in the same build, but are missing right now:

  • Integration Tests (mainly: Application servers, UI with Selenium, etc)
  • Builds with higher Java versions
  • Tests against different databases with Testcontainers (they exist, are currently disabled)
2 Likes
3

If there is not the need to build something heavy each day, we can also set up a weekly build.
The nightly could gradually increase, and specific features might be enabled/disabled by workflow parameters.

4

I think the integration tests would be nice in a nightly, as our code is currently moving quite fast and gets a lot of updates.

For several JDK tests and database tests, weekly would definitely be enough

1 Like
5

Sounds like a plan. Do you know what it takes to enable integration tests? If not, I’ll find that out.

6

I found some references in Camundas CI pipeline / Jenkinsfiles, it’s manily a combination of Maven profiles:

1 Like
7

I would just run everything we have every night. If it does not take the whole night, why not.

8

I’m not in favor of using resources if they are not needed, just because we could. Builds waste huge amount of energy. Do we have a real benefit of building against each (supported) Java release and each OS each night? I doubt. Though building frequently or on demand should be done.

1 Like
9

I will have a look at those to get impressions

10

I agree that we should aim to use resources responsibly. However, I believe the energy spent on testing and building isn’t inherently wasted.

GitHub has been carbon neutral since 2019 and plans to run entirely on renewable energy by 2025 (see GitHub’s sustainability efforts).

As for building against each Java release and OS nightly, I get the skepticism. But when changes occur in the code, I find it incredibly valuable to run all relevant tests to catch issues early. The real cost of skipping tests could be recognizing a problem days or weeks later, making it far harder to debug and fix.

That said, I’m all for smarter optimization - if there’s no change in the underlying code, triggering unnecessary builds can and should be avoided.

1 Like
11

Of course running any available combination of the integration tests does not make sense either and would be of course wasteful, we should pick some common configurations as default.

1 Like
12

For now, adding more features into the nightly build is the next step to go. If you have concrete feature requests, raise an issue, I will care for it.

1 Like
13

The Nightly Build builds now against Java 17 and Java 21.

Furthermore it attaches now additionally the distributions Wildfly & WebJar as separate downloadable artifacts.

A bit unfortunate is that the download is a .zip, which itself contains the archive as .tar.gz.

Same is now for the regular build, but it does only create the Tomcat bundle and builds against a single Java 17 version.

Bildschirmfoto 2024-12-03 um 10.12.15
Bildschirmfoto 2024-12-03 um 10.12.151002×463 22.9 KB

2 Likes
14

Nice! Would it be also possible to generate the operaton run distribution as artifact?

15

The run distro is not yet in the reactor. It has been commented out in the /pom.xml so far. I once activated it and saw a compile issue, and did not dig into it further. Likely not much to do to get it into the build. And then of course it could be added.
I’m thinking about adding this after the beta-2 release. Slowly I want to come to an end with that release procedure and not have even more open ends.

2 Likes
16

Yes let’s do the run/docker builds in beta-3

2 Likes
17

Yes, I will work on it.

18

OperatonRun builds was prepared via fix(build): Enable `run` in `distros` profile & build nightly by kthoms · Pull Request #332 · operaton/operaton · GitHub

The nightly build offers the distro for download:

1 Like
19

I have worked yesterday evening on the Nightly Build. It uses now also JReleaser to publish an “early-access” release. This has been finished this morning.

The release and its artifacts are now available at a static URL:

1 Like