[JIRA] (JENKINS-59071) Git should include an option to "checkout the revision at build-time"
Title: Message Title Christoph Läubrich commented on JENKINS-59071 Re: Git should include an option to "checkout the revision at build-time" Tobias Gruetzmacher thanks for taking care of this, maybe CloneOption/reference is usefull but from the documentation I can't guess how it is supposed to work :-\ There is also a CloneOptionTrait/reference but no idea whats the deffirence...? Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.201453.1566731724000.7800.1581500820235%40Atlassian.JIRA.
[JIRA] (JENKINS-59071) Git should include an option to "checkout the revision at build-time"
Title: Message Title
Christoph Läubrich commented on JENKINS-59071
Re: Git should include an option to "checkout the revision at build-time"
Thanks for taking a look into this, from my point of view I won't say it is a bug but more a feature request, that's why I marked it as a new function, and would expect to find it as a new behavior or maybe added to the 'advanced checkout behaviors'. Our build combines artifacts from different source repositories int one final artifact, for different reasons we can't just merge them or build them independently, but beside from that the case can be generalized to have two source.repositories Master + Child:
Master contains a Jenkinsfile and is used in a multi-branch-pipeline, and uses 'checkout scm'
The Jenkinsfile of Master later on contains 'checkout scm Child'
a Jenkinsfile might look something like this:
steps {
checkout([$class: 'GitSCM', branches: [[name: '*/master']], userRemoteConfigs: [[url: 'http://master/repro']]])
sh 'mvn clean install master/pom.xml'
checkout([$class: 'GitSCM', branches: [[name: '*/master']], userRemoteConfigs: [[url: 'http://child/repro']]])
sh 'mvn clean install child/pom.xml'
sh 'aggregation.sh'
}
What happens now is, that while the part in Jenkinsfile is running before the 'checkout scm Child' someone pushes a new commit to Child and when the pipeline reaches that step it fetches the new commit and thus building 'Child' in a different (from the point of happens-before-relation) version than 'Master' So what would be needed is some kind of checkout behavior that not checkouts 'specific revision which triggered this Pipeline run but checkouts 'most recent revision when the build starts', something like
git checkout 'master@{BUILD_DATE}'
Add Comment
[JIRA] (JENKINS-59071) Git should include an option to "checkout the revision at build-time"
Title: Message Title Christoph Läubrich created an issue Jenkins / JENKINS-59071 Git should include an option to "checkout the revision at build-time" Issue Type: New Feature Assignee: Mark Waite Components: git-plugin Created: 2019-08-25 11:15 Priority: Minor Reporter: Christoph Läubrich Currently the git-plugin can checkout the current head, or a specific commit, what I'm missing is an option to checkout the head at the time where the build has started. Reason: if you have a pipeline build that was triggered at a certain time, and the devlopers checked in something before the checkout takes place these changes are picked up even if the build is already running for a while. For example I have a pipeline that builds different repositories together one after the other. It now can happen that a build starts, checkout the first repository, then checkout the second but picks up changes commited at a later point at time (and fail because changes from the first repository are not taken into account). The same happens if you replay a certain pipeline build, it always fetches the ltest changes and not the changes that where current at the time of the build (so replay is more a "rebuild with different script" because the build is not really replayed.
[JIRA] (JENKINS-59070) Declarative Pipeline should allow to decalre required plugins
Title: Message Title
Christoph Läubrich created an issue
Jenkins / JENKINS-59070
Declarative Pipeline should allow to decalre required plugins
Issue Type:
New Feature
Assignee:
Unassigned
Components:
pipeline
Created:
2019-08-25 11:08
Priority:
Minor
Reporter:
Christoph Läubrich
Currently it is possible to declare used tools for a declarative pipeline, it would be good to have an additional
plugins {
'extmail',
'slack',
''
}
section where a pipeline can declare required plugins. Before the pipeline build starts, the code should check that the plugin is installed and if not halt the build with a notification (like input step) to ask the user if he wants to install the required plugins. If yes is choosen, the user is taken to the pluginmanager with all required plugins preselected.
Add Comment
[JIRA] (JENKINS-56536) currentBuild.currentResult not set to failed
Title: Message Title Christoph Läubrich commented on JENKINS-56536 Re: currentBuild.currentResult not set to failed We also have this problem, this is critical for us since now all E-Mails and anouncements always state that the build is successfull! Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-56536) currentBuild.currentResult not set to failed
Title: Message Title Christoph Läubrich updated an issue Jenkins / JENKINS-56536 currentBuild.currentResult not set to failed Change By: Christoph Läubrich Priority: Minor Critical Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-6268) Make checking for modification time of junit results be configurable and off by default
Title: Message Title Christoph Läubrich commented on JENKINS-6268 Re: Make checking for modification time of junit results be configurable and off by default Is there any progress on this? We are also hit by this, so currently we have only the option to disable junit recording at all... Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-16423) Add option for CC and BCC
Christoph Läubrich commented on JENKINS-16423 Add option for CC and BCC A thank you, is this documented somewhere? Might be good to add it to the Jenkins Help for "Project Recipient List" This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16424) Add Parameter to use the Name of Recipient
Christoph Läubrich commented on JENKINS-16424 Add Parameter to use the Name of Recipient It would be nice to have something like: "Hi , ..." in the mail body to make the mail apear more personal. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-6922) PROJECT_URL variable not correctly set when email is sent by Promoted Build Plugin
Christoph Läubrich commented on JENKINS-6922 PROJECT_URL variable not correctly set when email is sent by Promoted Build Plugin The same problem occurs with the build number. This could be fixed by using PROMOTED_NUMBER and PROMOTED_SVN_REVISION env variable, from what is shown here: https://github.com/jenkinsci/promoted-builds-plugin/blob/master/src/main/java/hudson/plugins/promoted_builds/Promotion.java you can use the PROMOTED_URL for the URL part. Beside this, it would be nice to allow to trigger a mail when a promition occurs (not sure if this is possible) so you not need to wrap the mail configuration in a a promotion directly. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16424) Add Parameter to use the Name of Recipient
Christoph Läubrich created JENKINS-16424 Add Parameter to use the Name of Recipient Issue Type: Improvement Assignee: Slide-O-Mix Components: email-ext Created: 21/Jan/13 8:14 AM Description: The name could either be derived from the e-mail, locked up in jenkins or taken from the email in format " myn...@company.test" Project: Jenkins Priority: Major Reporter: Christoph Läubrich This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16423) Add option for CC and BCC
Christoph Läubrich created JENKINS-16423 Add option for CC and BCC Issue Type: Improvement Assignee: Slide-O-Mix Components: email-ext Created: 21/Jan/13 8:12 AM Description: It would be nice to specify a mails CC and BCC header Project: Jenkins Priority: Major Reporter: Christoph Läubrich This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14226) Restrict where this project can be run, does not work anymore
Christoph Läubrich updated JENKINS-14226 Restrict where this project can be run, does not work anymore Change By: Christoph Läubrich (29/Jun/12 9:33 AM) Component/s: promoted-builds This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14226) Restrict where this project can be run, does not work anymore
Christoph Läubrich commented on JENKINS-14226 Restrict where this project can be run, does not work anymore I can aprove that downgrading Promoted Builds Plugin to 2.5 fix the problem. Should this Bug the assigned to the 'Promoted Builds Plugin' or is it a core problem? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14226) Restrict where this project can be run, does not work anymore
Christoph Läubrich updated JENKINS-14226 Restrict where this project can be run, does not work anymore Change By: Christoph Läubrich (29/Jun/12 9:17 AM) Priority: Major Blocker This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14226) Restrict where this project can be run, does not work anymore
Christoph Läubrich commented on JENKINS-14226 Restrict where this project can be run, does not work anymore Same Problem here on Jenkins ver. 1.472 running at Linux dev 2.6.32-41-server #90-Ubuntu SMP Tue May 22 12:41:40 UTC 2012 x86_64 GNU/Linux This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12849) NullPointerException when parsing changeset
Christoph Läubrich created JENKINS-12849: Summary: NullPointerException when parsing changeset Key: JENKINS-12849 URL: https://issues.jenkins-ci.org/browse/JENKINS-12849 Project: Jenkins Issue Type: Bug Components: mantis Environment: Hudson ver. 2.2.0, Linux/Debian Reporter: Christoph Läubrich Assignee: sogabe Happens to me on Version 0.10.1 of the plugin ERROR: Publisher hudson.plugins.mantis.MantisIssueUpdater aborted due to exception java.lang.NullPointerException at hudson.plugins.mantis.Updater.findChangeSetsFromSCM(Updater.java:136) at hudson.plugins.mantis.Updater.findChangeSets(Updater.java:120) at hudson.plugins.mantis.Updater.perform(Updater.java:55) at hudson.plugins.mantis.MantisIssueUpdater.perform(MantisIssueUpdater.java:53) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:630) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:608) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:584) at hudson.model.Build$RunnerImpl.post2(Build.java:159) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:553) at hudson.model.Run.run(Run.java:1390) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:145) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
