nebula-plugins / nebula-plugins/nebula-release-plugin
Cannot run Nebula in a Jenkins Pipeline child job
Nobody has claimed this yet.
- Dominant language
- Groovy
- Stars
- 236
- Forks
- 60
- Avg merge
- 10m
- Merged PRs (30d)
- 4
Description
This really is a bug/issue with Nebula, but it requires some background that sounds like we're filing a Jenkins bug. Please bear with me.
CONTEXT:
We have a Jenkins multibranch pipeline job that builds and tests a git repo, uses the Nebula release plugin to version the jars, and calls a sign/publish job that pushes jars to Artifactory. This all works perfectly.
Now we want to move the Nebula and sign/publish parts of the job to a separate Jenkins job, and call it from the main job.
The separate Jenkins job needs to be configured with a different Jenkinsfile, but in the same repo as the main job.
The only suitable type of Jenkins job to do that with is a Jenkins Pipeline job (not muiltibranch). This type of job is not triggered by a developer's commit (which is correct for this use case). And this type of job allows specifying a Jenkinsfile. It also can be parameterized, which is proving important, as explained in a bit.
Unfortunately, there is a known problem in Jenkins where Jenkins Pipeline jobs are not passed the SCM context from the parent job (https://issues.jenkins-ci.org/browse/JENKINS-52059). We had to work around this by parameterizing the child Jenkins job and setting the parameters in the environment inside the called job's Jenkinsfile.
NOW BACK TO NEBULA:
Before we passed in GIT_LOCAL_BRANCH as a parameter to the child job, Nebula was failing with "This test run was triggered on the branch origin/master, while semantic-release is configured to only publish from master, therefore a new version won’t be published."
Passing in the parameter got us past that problem, so we know 1) parameter passing is working between parent and child jobs, and 2) Nebula sees the values we pass in.
Unfortunately, we are now seeing this in the news announcing the release: "jenkins multi-poc@0.0.0-semver.auto.generated is now available. fix: Test comment".
It's clear that Nebula doesn't know what the version should actually be. We suspect there is some more info in the parent job that we need to pass to the child job, but we don't know what Nebula needs. Can you tell us?
Also, when we call the sign/publish job from the child job, it fails with: "org.gradle.execution.TaskSelectionException: Task 'snapshot' not found in root project 'multi-poc'.".
The "snapshot" is introduced when the Nebula release plugin is applied, and we only apply it in the child job. So why did it disappear? Is that a piece of information we need to pass from the child job to the sign/publish job? If so, what do we need to pass? Keeping in mind that this worked perfectly before we moved Nebula to a child job.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the parent, child, and sign/publish Jenkinsfiles described in the issue, then inspect how Nebula obtains branch and release context and applies the snapshot task. Reproduce the child-job flow with the reported parameters and compare it with the previously working single-job flow. Done means the child and publish jobs retain the correct version and snapshot task behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- groovy
- Domain
- build-system, ci-cd, release
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100