We have a Jenkins instance to run the CI checks on our GitHub.com private repositories. The workload for Jenkins is 100% under Kubernetes with 100% ephemeral agents, which means we need to be thrifty with how we interact with Git, including cloning, etc…
When the pipeline starts, Jenkins will fetch the Jenkinsfile, but for a PR it will merge the PR branch with the target branch to get the resolved file so that the pipeline will work as it would after the changes are merged.
The first few lines of the console output would be something like:
00:00:00.000 Pull request #123 updated
00:00:00.252 19:01:15 Connecting to https://api.github.com using 12345/******
00:00:01.483 Obtained Jenkinsfile from 8017549f36f4ba37c0979605ccf481a97d1c30e7+95dc3f9bf535133f180ed2dfe9906ab10ddb0efa (60a317e07a25ab734bcd4ca8816b171fe50fec68)
It seems that this comes from the SCMBinder.java file in the Multibranch plugins.
Now we have a custom jenkins library that has a pipelineInit() method that we call before the pipeline {} block. This allows us to fetch additional configuration information such as which containers to use for the stages. Today we use https://raw.githubusercontent.com/<org>/<repo>/<branch>/<filename> to get that config file, but if there is a change in the target branch for that file then our pipeline fails checks later on until the user rebases, and re-runs the pipeline a third time since githubusercontent does return the new file right away (eventual consistency issue).
To fix this issue I’m looking for a way to call the same logic that resolves the merged Jenkinsfile and use that to get the merged config file. Unfortunately I could not find any documentation from GitHub on how to do this and my Java skills are not strong enough .
As far as I can tell I would need to do something of the sort:
def fs = SCMFileSystem.of(scmSource, head, rev)
def confYaml = script = fs.child(confPath).contentAsString()
def conf = readYaml(text: confYaml)
I’m not clear if that’s the right approach from a jenkins library, but if we can get this to work this should help reduce these odd pipeline failures.
Note that I posted a similar question a few months ago: