Refactoring Jenkinsfile at bit - #340
Draft
AnHeuermann wants to merge 4 commits into
Draft
Conversation
.CI/Jenkinsfile holds the stages; what they do is a function in .CI/common.groovy, or in .CI/report.groovy for the pages published from the results. A setup stage loads both and the stages reach them as common.<function>() and report.<function>(), the split the OpenModelica repository uses for its own pipeline. Loading them is a stage of its own because every stage that tests a branch skips the checkout that would otherwise bring the files into its workspace. The report stage shrank the most: report.py followed by `mv overview.html <page>` was written out twenty times and is an overview() call now, and the four pages that -oldinst, -fmi, -dae and -newbackend-dae each produce are one overviewSet(). It runs the same commands in a different order, which no page depends on. Two things changed while moving: - The locals of runRegressiontest are declared with def. Without it they land in the binding the whole pipeline shares, where the stages running in parallel overwrite each other's. - The FMI jobs of the maintenance branches build OMSimulator from origin/master rather than master. git fetch does not update a local branch, so resetting to one kept whatever commit another job had left in the shared workspace. All six jobs take the ref from one variable now. A new workflow lints every Jenkinsfile and *.groovy with npm-groovy-lint and the rules in .groovylintrc.json: a syntax error is reported as an error and anything the rules complain about as a warning, both of which fail the job, so a Jenkinsfile that does not parse is found before a build runs it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
An action named by a tag is whatever that tag points at on the day the workflow runs. The workflows name the commit now, with the release it belongs to in a comment, and every action is updated to its newest release while at it: checkout v4 to v7.0.1, setup-python v5 to v7.0.0, upload-artifact v4 to v7.0.1 and setup-openmodelica v1 to v1.1.0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
runRegressiontest took an `omcompiler` flag choosing between the compiler directory of the OpenModelica repository and a standalone OMCompiler clone next to it, the layout from before the compiler moved into the repository. Every one of the 24 call sites passed false, so the parameter, the OMCPATH it picked, the guard against combining it with a cmake build, the clone of OMCompiler.git and the `rm -rf OMCompiler` that removed a leftover submodule directory are gone. OMLibraries was cloned with all its submodules, fetched and reset on every run for a `make -C ../OMLibraries` that has been commented out for as long: the libraries a run tests are the ones installLibraries() installs through the OpenModelica package manager. The clone is gone with it. The same goes for the omlibrary leftovers: `--with-omlibrary=all` is not an option of configure any more - configure.ac has one AC_ARG_WITH, cppruntime - and build/lib/omlibrary is not where a build puts libraries any more, so emptying it removed nothing and created an empty directory nothing reads. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
One shell string of sixty lines checked out the sources, decided whether the cached build was still good and built omc when it was not, with the build itself interpolated into it from a second string a branch above. It is four functions now: - checkoutOMC() clones, resets and checks out the branch or the pull request ref, and updates the submodules. - buildOrRestoreOMC() decides between the cache in ~/saved_omc/<name> and a build, and runs the one it picks. - cmakeBuild() and autoconfBuild() are the two builds it picks from. The shell they run is the shell that ran before, with one line added: the build is a second sh, so it enters the directory the checkout left off in. withSccache now wraps the build alone rather than the checkout as well, which never needed the compile cache in its environment. The cleans of the checkout say -ffdx. A single -f skips an untracked directory that is a repository of its own, which is exactly what a submodule that has been dropped leaves behind: OMCompiler/3rdParty/sundials-5.4.0 has been sitting on the nodes since sundials became a submodule of its own name. The clean of the OpenModelica checkout keeps libraries/git, the reference file clones test.py fills GITREPOS with, which -ff would otherwise remove on every run. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
AnHeuermann
force-pushed
the
clean-up-jenkins
branch
from
August 27, 2026 15:40
87dff40 to
b59976c
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Issue
The Jenkinsfile is a hot mess.
Changes