Closed bicschneider closed 6 years ago
Will be problematic for 100% of users, as this seems to be the usual way write scripted pipeline jobs.
I have a commit on a ready branch, with an updated Jenkinsfile. It is different from the one on master.
Problem is shown here in this pipeline job in the UI - what happens is we use a git extension to merge our ready-branch with master before we "build" the pipeline from Jenkinsfile
.
So the pipeline will be described from my latest Jenkinsfile merged with master. That is OK.
But what happens in the pipeline, when we run what-ever is in the Jenkinsfile
, is not run on the merged workspace.
In the above example we show it using usual git extension behavior, but our pretested integration git extension have the same problem.
Documentation about this can be pitfall and what the user should be aware of. It can be said in about 2-3 lines.... similar to:
Be aware about where you place the pretested integration step if using Jenkins Pipelines, as the pipeline job itself do not necessarily run on the same SCM checkout as the stages in the Pipeline, thus the Jenkinsfile defining the pipeline can be different (as in unmerged with master) in some occasions.
We conclude we can't solve the problem as we can't detect safely if the pipeline is changed. This is because that even though we could check in git if there are changesets on the pipeline description file, we can't know about any includes in the groovy syntax, so we can't sure detect it.
We also discussed that it might no be our problem to solve, as all other plugins that merges workspaces work this way. The pitfall is the same.
So solution is when you write your jobs, you would in case you will have to handle all scenarios, have to make sure that the pipeline job merges, and that all stages then use the same merged workspace.
I'm adjusting estimates to fit the delivery.
Is this something we would add to the official documentation, or can we just close this issue
Yes, we will need to add it to the official docs, but it is a rare case so we will do our pre-release first.
docs for the Jenkinsfile @MadsNielsen @buep
jenkinsfile
The default behaviour of the pretested integration plugin is to run jenkinsfile
that is located on the branch that is being integrated, so if branch ready/457-uses-gradle-instead-of-maven
if being processed by the plugin, it is the file located on that branch that will be executed, not the one on the integration branch.
There can be cases where users have edited the jenkins file, and that can result in a merge conflict. The pretested integration plugin does not handle merge conflict in a Jenkinsfile, so to update the Jenkins file, another strategy must be applied.
master
) locally in a separate commit If master
(in the case above) is also being build by a job, that can result in a failing build if the new Jenkinsfile is using resources not yet available. This will however be fixed the moment the ready
-branch have been integrated.
Closing, I reference the documentation in #96 so we remember to copy paste in what you prepared above for us.
Issue It is important that we handle this scenario (comment) which is mentioned on the Git Plugin PreMerge feature. The Jenkinsfile might not merged before loaded..: https://gist.github.com/martinda/b2ece95c2c71ddb4d4a762f0a02561b3#gistcomment-2016232
In case the Pipeline script is loaded via SCM and does not have Git Phlow or Merge extension enabled then the "wrong" Pipeline is executed in the following scenario: