-
Bug
-
Resolution: Not A Defect
-
Major
-
None
-
Powered by SuggestiMate
When i creat a new job by copying another job, the first poll does not run.
Even when i click "poll now" the poll does not seem to run.
If i open the configuration of the new job and save, the polling starts to work.
Any ideas what the problem is? I am happy to provide logs but i am unsure which loggers to use?
This is causing major problems for us because we have automated job creation to copy a template job. At the moment all these jobs need to be manually re-saved in order to run which is causing much delay.
[JENKINS-30745] First poll does not run on copied jobs which aren't yet saved or applied
integer It used to work and now it does not. Also why are copied jobs not buildable by design? They exist and have a configuration. Why do you want to force it to re save.
This essentially stops this from working: https://entagen.github.io/jenkins-build-per-branch/
yakobe can you help with a little more information?
What was the last version where you know it worked?
What plugin versions are you running now?
What steps do I need to take to duplicate the problem?
I'd prefer that you respond with more detail and fewer steps than "implement everything described at https://entagen.github.io/jenkins-build-per-branch/ ", unless that is truly the simplest way to duplicate the problem. That looks like it will take several hours for me to construct a repeatable case, and I'm not confident where it will fail or how it will fail. When I need to spend several hours duplicating a bug report, it reduces the time I can spend on the other aspects of the git plugin and the git client plugin. If it is that involved to duplicate the problem, it will likely be several weeks before I'm able to investigate.
You said:
When i creat a new job by copying another job, the first poll does not run.
Even when i click "poll now" the poll does not seem to run.
If i open the configuration of the new job and save, the polling starts to work.
Steps I tried (define a new job, edit the job definition):
- Define a new job "
JENKINS-30745-copied-job-does-not-poll" as a copy of existing job "git-client-plugin-my-coverage" - Simplify the configuration of the new job before saving it
- Save the new job definition
- Click "Poll Now", confirm polling works
Steps I tried (define a new job without editing the job definition):
- Define a new job "
JENKINS-30745-copied-job-does-not-poll-no-edit" as a copy of existing job "JENKINS-21553-maven-https-NPE" - Save the new job definition
- Click "Poll Now", confirm polling works
Maybe you have a different way of creating the copied job which doesn't pass through the same route as the user interface that I used?
Steps I tried (command line copy a job without editing job definition):
- java -jar jenkins-cli.jar -s http://localhost:8080/ copy-job JENKINS-23415-wildcard
JENKINS-30745-cli-copied - Open Jenkins UI, press "Poll now" on
JENKINS-30745-cli-copied, confirm polling works
You may also want to experiment with the multi-branch plugin. It automatically creates jobs when a branch is created, and automatically deletes jobs when a branch is deleted. I've found that I use it frequently for development on the git client plugin and the git plugin.
Thanks for the feedback. I'll try to provide as much info as i can. I think that the entagen script does not save the new job definition in the same way.
If i follow your steps:
Steps I tried (define a new job without editing the job definition):
Define a new job "
JENKINS-30745-copied-job-does-not-poll-no-edit" as a copy of existing job "JENKINS-21553-maven-https-NPE"
Save the new job definition
Click "Poll Now", confirm polling works
Then polling also works. If i do this instead (i.e. dont do the second step)
- Define a new job "
JENKINS-30745-copied-job-does-not-poll-no-edit" as a copy of existing job "JENKINS-21553-maven-https-NPE" Save the new job definitionVisit the new job from the dashboard without saving first- Click "Poll Now"
Then polling does not happen. I have to go in and re-save to get it to work.
The entagen script seems to leave the job in the same status.
As i say, this worked until several weeks ago. Unfortunately i dont know what was the last version where it was ok because i thought it was just a small break and would be fixed in the next / upcoming release (happens sometimes).
I can provide logs etc if you let me know what could be useful
I don't understand how a job copied from the UI but not saved would be expected to work "out of the box". I think the act of saving (or applying) the job is a critical part of the job creation, and until that is done, I assume that the job is not completely initialized. However, that is just a supposition on my part, not something I can say is fact based on experiments or review of the code.
Can you alter your process to use the same copy-job process as is done by the jenkins-cli.jar when it runs as a command line job? It seems to perform a sufficient copy for polling, without requiring that you do anything more than run the command line jar.
I appreciate the offer to share logs, but analyzing log files shifts the bulk of the investigation to me. There are many more submitters of bug reports and pull requests than there are plugin maintainers. I need as much help from bug reporters and pull request submitters as I can get so that I can help as many people as possible as effectively as possible.
I could understand that if the job did not exist until you click the `save` button on the configuration. However, since it is created and exists without saving i feel it should work. I.e. i just copied the job with a new name, it takes me to the config page but i dont need to change anything else.
Also why are copied jobs not buildable by design? They exist and have a configuration. Why do you want to force it to re save.
Because
I think the act of saving (or applying) the job is a critical part of the job creation, and until that is done, I assume that the job is not completely initialized.
See JENKINS-30802
The problem is that changing it to force a save is breaking backwards compatibility... not a huge problem but perhaps needs a bigger announcement
I could agree that
I think the act of saving (or applying) the job is a critical part of the job creation, and until that is done, I assume that the job is not completely initialized.
But only if the job does then not actually exist until you press save. Otherwise you end up with a job in a non-initialised state.
Maybe it would be better to add an option to disable newly copied jobs at first, so you have a chance to make your configuration changes before it starts to build?
You said:
The problem is that changing it to force a save is breaking backwards compatibility... not a huge problem but perhaps needs a bigger announcement
I think that is not a change in the git plugin or the git client plugin, but rather a change in Jenkins core components. At least that is my first guess based on comments by integer in JENKINS-30802.
I propose to reassign this bug to jenkins core, since the problem seems related to the invocation of polling and the state of the job prior to the save, rather than to anything within the git plugin or git client plugin.
There is no bugs because polling shouldn't work for disabled jobs. Enhancement issue i already opened.
Even if polling trigger build for disabled job it will be skipped by queue that doesn't make any sense and causes performance degradation for jenkins. So there is no bugs/regressions here.
I'm not sure if i quite understand you there, sorry. Just for clarity: the newly created job is not disabled at the moment. if it was then it would at least be consistant. At the moment it creates a job that will not run but looks like it is all 'ready to go'
Copied in UI job and not saved via button in UI = is not buildable. Is not buildable jobs are skipped everywhere (queue/trigger run etc).
Ok... as long as it can still be discussed i will not reopen. (if nobody see this because it is resolved i will have to re-open.).
There is definitely a bug here. And the problem is not resolved for me. I have also discovered another problem caused by this:
You say the builds are marked 'unbuildable' you just dont see it in the UI. However it is possible to manually start the build. After the job has run the polling still does not work. *This is inconsistant and is causing serious problems in our workflow! The builds are not running when the git repo is updated *
I would say it is not a bug if
- the job does not exist until you click the 'save' button
- the job is disabled
- the job visually says it is 'unbuildable' (and you cannot start the build manually)
However this is not the case. Therefore BUG
Also... if you restart jenkins. All those previously 'unbuildable' jobs suddenly become magically buildable and start running
All this logic is the same for all triggers and test cases, everybody enforce to do roundtrip (open config/save). So this is not a bug but pure designed api that was concentrated on UI (and obviously those who entered such "feature" (obvioulsy why it done) forget to raise it into UI). So this should be an enhancement that i linked to this issue.
yakobe please add this comments to JENKINS-30802 because i fully agree that this is bad and unexpected behaviour.
What about the cases i mention?
After the job has run [manually] the polling still does not work
and
if you restart jenkins. All those previously 'unbuildable' jobs suddenly become magically buildable and start running
and also the fact that it used to work but now it does not
integer do you know of a way to force a copied job to be buildable over the api? Otherwise you cannot copy a job with the api anymore (you have to go in and save it manually). I really need to find a work-around for our issue
Can't you use the jenkins-cli.jar copy-job command to perform the copy? Alternately, if you need to do it through some other programming language, you could read the source code of the jenkins-cli.jar copy-job command to see what additional steps it takes compared to the calls you're making with the API you are using.
We are using a 3rd party script to control our jobs. This line is where the job is cloned: https://github.com/entagen/jenkins-build-per-branch/blob/master/src/main/groovy/com/entagen/jenkins/JenkinsApi.groovy#L54. The problem is that the new changes mean that new jobs cannot be created over the api anymore (unless there is some way to say they are buildable).
Guys, that's all dirty hack and pure jenkins API/code place. Solution should be provided/resolved through JENKINS-30802
integer I'm a bit confused again by what you mean. Are you saying that copying a job with the API is a hack? Or are you saying that JENKINS-30802 will provide a solution to allow jobs to be copied over the API? From my view it should be possible to copy jobs using the API...
integer I see you updated your message but it is still not clear what you mean. Even if i use the standard rest API (not the scripts from entagen) i am not able to copy a job and get it to a state where polling works (due to the changes with this activation stuff). It really feals like a bug
yakobe IIRC newly copied jobs should have no "Build Now" link in the sidepanel until you save the config form. Are you saying that's not the case?
Code changed in jenkins
User: Oleg Nenashev
Path:
changelog.html
http://jenkins-ci.org/commit/jenkins/f53b529fa0f7abb3e936b3c19214ee20116b811c
Log:
Noting the revert of https://github.com/jenkinsci/jenkins/pull/1617 in #1870 (JENKINS-30745)
Copied job is not buildable, you should re-save configuration, works as designed.