-
New Feature
-
Resolution: Won't Do
-
Minor
-
Windows, current Git-plugin
In our Jenkins build server we have a number of freestyle build jobs. Those build jobs are all working in the same workspace and each of those build jobs is calling another one after being finished: A->B->C->D->.... which is very time consuming. All build jobs have been configured for the same git repository to be able to track which developers contributed to the build and to checkout the same commit in each build. ... Some of those build jobs should be able to run in parallel since they only execute unit tests in separate subdirectories.
To minimize execution time of the whole build chain we wanted to execute build jobs B, C and D in parallel: A->[B,C,D,...].
Unfortunately, when B,C and D are started at the same time, they are all trying to fetch from the origin repository via git and store the update in the very same workspace's .git directory, which in the end results in failed builds for B, C and D.
The error message in the build looks similar to this in such cases:
...
[new branch] feature -> origin/feature
error: cannot lock ref 'refs/remotes/origin/feature/task': is at d91b4e33b4a2d3404c0738c85b39314bb1d3c2be but expected 1b9026360df650a3ae1e224e09e92373fcafd9ef
I think a workaround would be here to add an option in the git configuration to prevent polling of the git repository at all. Indeed, this option is already available for pipeline build jobs
, but for freestyle ones it is missing.
Can we have this option implemented also for freestyle build jobs?
https://www.jenkins.io/doc/pipeline/steps/git/ - Search for "Example: Git step with https protocol and polling disabled"
[JENKINS-71647] Add option to prevent git fetch for freestyle projects
Uwe Scholz
created issue -
Uwe Scholz
made changes -
| Description |
Original:
On our build environment we have a number of freestyle build jobs. Those build jobs are all working in the same workspace and each of those build jobs is calling another one after being finished: A->B->C->D->.... which is very time consuming. All build jobs have been configured for the same git repository to be able to track which developers contributed to the build and to checkout the same commit in each build. ... Some of those build jobs should be able to run in parallel since they only execute unit tests in separate subdirectories.
To safe execution time of the whole build chain we wanted to execute build jobs B, C and D in parallel: A->[B,C,D,...]. Unfortunately, when B,C and D are started at the same time, they are all trying to fetch from the origin repository via git and store the update in the very same workspace's .git directory, which in the end results in failed builds for B, C and D. The error message in the build lock looks similar to this in such cases: * [new branch] feature -> origin/feature error: cannot lock ref 'refs/remotes/origin/feature/task': is at d91b4e33b4a2d3404c0738c85b39314bb1d3c2be but expected 1b9026360df650a3ae1e224e09e92373fcafd9ef I think a workaround would be here to add an option in the git configuration to prevent polling of the git repository at all. Indeed, this option is already available for pipeline build jobs(*), but for freestyle ones it is missing. Can we have this option implemented also for freestyle build jobs? (*) [https://www.jenkins.io/doc/pipeline/steps/git/] - Search for "Example: Git step with https protocol and polling disabled" |
New:
In our Jenkins build server we have a number of freestyle build jobs. Those build jobs are all working in the same workspace and each of those build jobs is calling another one after being finished: A->B->C->D->.... which is very time consuming. All build jobs have been configured for the same git repository to be able to track which developers contributed to the build and to checkout the same commit in each build. ... Some of those build jobs should be able to run in parallel since they only execute unit tests in separate subdirectories.
To safe execution time of the whole build chain we wanted to execute build jobs B, C and D in parallel: A->[B,C,D,...]. Unfortunately, when B,C and D are started at the same time, they are all trying to fetch from the origin repository via git and store the update in the very same workspace's .git directory, which in the end results in failed builds for B, C and D. The error message in the build lock looks similar to this in such cases: * [new branch] feature -> origin/feature error: cannot lock ref 'refs/remotes/origin/feature/task': is at d91b4e33b4a2d3404c0738c85b39314bb1d3c2be but expected 1b9026360df650a3ae1e224e09e92373fcafd9ef I think a workaround would be here to add an option in the git configuration to prevent polling of the git repository at all. Indeed, this option is already available for pipeline build jobs(*), but for freestyle ones it is missing. Can we have this option implemented also for freestyle build jobs? (*) [https://www.jenkins.io/doc/pipeline/steps/git/] - Search for "Example: Git step with https protocol and polling disabled" |
Uwe Scholz
made changes -
| Description |
Original:
In our Jenkins build server we have a number of freestyle build jobs. Those build jobs are all working in the same workspace and each of those build jobs is calling another one after being finished: A->B->C->D->.... which is very time consuming. All build jobs have been configured for the same git repository to be able to track which developers contributed to the build and to checkout the same commit in each build. ... Some of those build jobs should be able to run in parallel since they only execute unit tests in separate subdirectories.
To safe execution time of the whole build chain we wanted to execute build jobs B, C and D in parallel: A->[B,C,D,...]. Unfortunately, when B,C and D are started at the same time, they are all trying to fetch from the origin repository via git and store the update in the very same workspace's .git directory, which in the end results in failed builds for B, C and D. The error message in the build lock looks similar to this in such cases: * [new branch] feature -> origin/feature error: cannot lock ref 'refs/remotes/origin/feature/task': is at d91b4e33b4a2d3404c0738c85b39314bb1d3c2be but expected 1b9026360df650a3ae1e224e09e92373fcafd9ef I think a workaround would be here to add an option in the git configuration to prevent polling of the git repository at all. Indeed, this option is already available for pipeline build jobs(*), but for freestyle ones it is missing. Can we have this option implemented also for freestyle build jobs? (*) [https://www.jenkins.io/doc/pipeline/steps/git/] - Search for "Example: Git step with https protocol and polling disabled" |
New:
In our Jenkins build server we have a number of freestyle build jobs. Those build jobs are all working in the same workspace and each of those build jobs is calling another one after being finished: A->B->C->D->.... which is very time consuming. All build jobs have been configured for the same git repository to be able to track which developers contributed to the build and to checkout the same commit in each build. ... Some of those build jobs should be able to run in parallel since they only execute unit tests in separate subdirectories.
To minimize execution time of the whole build chain we wanted to execute build jobs B, C and D in parallel: A->[B,C,D,...]. Unfortunately, when B,C and D are started at the same time, they are all trying to fetch from the origin repository via git and store the update in the very same workspace's .git directory, which in the end results in failed builds for B, C and D. The error message in the build lock looks similar to this in such cases: * [new branch] feature -> origin/feature error: cannot lock ref 'refs/remotes/origin/feature/task': is at d91b4e33b4a2d3404c0738c85b39314bb1d3c2be but expected 1b9026360df650a3ae1e224e09e92373fcafd9ef I think a workaround would be here to add an option in the git configuration to prevent polling of the git repository at all. Indeed, this option is already available for pipeline build jobs(*), but for freestyle ones it is missing. Can we have this option implemented also for freestyle build jobs? (*) [https://www.jenkins.io/doc/pipeline/steps/git/] - Search for "Example: Git step with https protocol and polling disabled" |
Uwe Scholz
made changes -
| Description |
Original:
In our Jenkins build server we have a number of freestyle build jobs. Those build jobs are all working in the same workspace and each of those build jobs is calling another one after being finished: A->B->C->D->.... which is very time consuming. All build jobs have been configured for the same git repository to be able to track which developers contributed to the build and to checkout the same commit in each build. ... Some of those build jobs should be able to run in parallel since they only execute unit tests in separate subdirectories.
To minimize execution time of the whole build chain we wanted to execute build jobs B, C and D in parallel: A->[B,C,D,...]. Unfortunately, when B,C and D are started at the same time, they are all trying to fetch from the origin repository via git and store the update in the very same workspace's .git directory, which in the end results in failed builds for B, C and D. The error message in the build lock looks similar to this in such cases: * [new branch] feature -> origin/feature error: cannot lock ref 'refs/remotes/origin/feature/task': is at d91b4e33b4a2d3404c0738c85b39314bb1d3c2be but expected 1b9026360df650a3ae1e224e09e92373fcafd9ef I think a workaround would be here to add an option in the git configuration to prevent polling of the git repository at all. Indeed, this option is already available for pipeline build jobs(*), but for freestyle ones it is missing. Can we have this option implemented also for freestyle build jobs? (*) [https://www.jenkins.io/doc/pipeline/steps/git/] - Search for "Example: Git step with https protocol and polling disabled" |
New:
In our Jenkins build server we have a number of freestyle build jobs. Those build jobs are all working in the same workspace and each of those build jobs is calling another one after being finished: A->B->C->D->.... which is very time consuming. All build jobs have been configured for the same git repository to be able to track which developers contributed to the build and to checkout the same commit in each build. ... Some of those build jobs should be able to run in parallel since they only execute unit tests in separate subdirectories.
To minimize execution time of the whole build chain we wanted to execute build jobs B, C and D in parallel: A->[B,C,D,...]. Unfortunately, when B,C and D are started at the same time, they are all trying to fetch from the origin repository via git and store the update in the very same workspace's .git directory, which in the end results in failed builds for B, C and D. The error message in the build lock looks similar to this in such cases: {{ [new branch] feature -> origin/feature}} {{ error: cannot lock ref 'refs/remotes/origin/feature/task': is at d91b4e33b4a2d3404c0738c85b39314bb1d3c2be but expected 1b9026360df650a3ae1e224e09e92373fcafd9ef}} I think a workaround would be here to add an option in the git configuration to prevent polling of the git repository at all. Indeed, this option is already available for pipeline build jobs(*), but for freestyle ones it is missing. Can we have this option implemented also for freestyle build jobs? (*) [https://www.jenkins.io/doc/pipeline/steps/git/] - Search for "Example: Git step with https protocol and polling disabled" |
Uwe Scholz
made changes -
| Description |
Original:
In our Jenkins build server we have a number of freestyle build jobs. Those build jobs are all working in the same workspace and each of those build jobs is calling another one after being finished: A->B->C->D->.... which is very time consuming. All build jobs have been configured for the same git repository to be able to track which developers contributed to the build and to checkout the same commit in each build. ... Some of those build jobs should be able to run in parallel since they only execute unit tests in separate subdirectories.
To minimize execution time of the whole build chain we wanted to execute build jobs B, C and D in parallel: A->[B,C,D,...]. Unfortunately, when B,C and D are started at the same time, they are all trying to fetch from the origin repository via git and store the update in the very same workspace's .git directory, which in the end results in failed builds for B, C and D. The error message in the build lock looks similar to this in such cases: {{ [new branch] feature -> origin/feature}} {{ error: cannot lock ref 'refs/remotes/origin/feature/task': is at d91b4e33b4a2d3404c0738c85b39314bb1d3c2be but expected 1b9026360df650a3ae1e224e09e92373fcafd9ef}} I think a workaround would be here to add an option in the git configuration to prevent polling of the git repository at all. Indeed, this option is already available for pipeline build jobs(*), but for freestyle ones it is missing. Can we have this option implemented also for freestyle build jobs? (*) [https://www.jenkins.io/doc/pipeline/steps/git/] - Search for "Example: Git step with https protocol and polling disabled" |
New:
In our Jenkins build server we have a number of freestyle build jobs. Those build jobs are all working in the same workspace and each of those build jobs is calling another one after being finished: A->B->C->D->.... which is very time consuming. All build jobs have been configured for the same git repository to be able to track which developers contributed to the build and to checkout the same commit in each build. ... Some of those build jobs should be able to run in parallel since they only execute unit tests in separate subdirectories.
To minimize execution time of the whole build chain we wanted to execute build jobs B, C and D in parallel: A->[B,C,D,...]. Unfortunately, when B,C and D are started at the same time, they are all trying to fetch from the origin repository via git and store the update in the very same workspace's .git directory, which in the end results in failed builds for B, C and D. The error message in the build looks similar to this in such cases: {{...}} {{[new branch] feature -> origin/feature}} {{error: cannot lock ref 'refs/remotes/origin/feature/task': is at d91b4e33b4a2d3404c0738c85b39314bb1d3c2be but expected 1b9026360df650a3ae1e224e09e92373fcafd9ef}} I think a workaround would be here to add an option in the git configuration to prevent polling of the git repository at all. Indeed, this option is already available for pipeline build jobs(*), but for freestyle ones it is missing. Can we have this option implemented also for freestyle build jobs? (*) [https://www.jenkins.io/doc/pipeline/steps/git/] - Search for "Example: Git step with https protocol and polling disabled" |
| Assignee | Original: Mark Waite [ markewaite ] |
Uwe Scholz
added a comment - Yes, indeed the build jobs all share the same workspace because of a reason: Build job A is fetching the initial sources from git (after a build was triggered externally) and it builds the executables for the unit tests, which are executed in B, C, D and so on. Since we are working on a very big mono-repo it would be a huge waste of disk space to give each unit test build job an own workspace. (in our case the repo size is like >2GB).
Apart from that, I wonder why the option to prevent polling is available for descriptive pipeline jobs, but not for freestyle jobs. Wouldn't it be good to align their options?
Uwe Scholz
added a comment - Yes, indeed the build jobs all share the same workspace because of a reason: Build job A is fetching the initial sources from git (after a build was triggered externally) and it builds the executables for the unit tests, which are executed in B, C, D and so on. Since we are working on a very big mono-repo it would be a huge waste of disk space to give each unit test build job an own workspace. (in our case the repo size is like >2GB).
Apart from that, I wonder why the option to prevent polling is available for descriptive pipeline jobs, but not for freestyle jobs. Wouldn't it be good to align their options? I believe you will have undesirable surprises that are difficult to diagnose due to your choice to have multiple concurrent jobs share the same Jenkins workspace.
I wonder why the option to prevent polling is available for descriptive pipeline jobs, but not for freestyle jobs. Wouldn't it be good to align their options?
Pipeline polling is controlled at a level above the git plugin.
You might compare the cost of diagnosis with the cost of additional disc space.
Alternatively, you might consider improving the performance of workspace creation by using a reference repository that keeps a copy of the large monorepo on the agent and uses the reference repository feature to only copy content that is not already in the reference repository. I created a video that describes reference repositories and other performance improvement tricks that I learned while wrestling with a 20+ GB repository.
I don't plan to implement this feature.
The message "cannot lock ref" is usually an indication that more than one job is attempting to use the same directory for its Jenkins workspace. If that is what is happening in your case, then you'll have unexpected results as the builds collide with each other in unexpected ways. Let Jenkins determine the workspace so that it avoids the collisions for you.