[JIRA] (JENKINS-50386) Job configuration Save/Apply buttons missing
Title: Message Title Tuukka Mustonen commented on JENKINS-50386 Re: Job configuration Save/Apply buttons missing Potentially duplicate of JENKINS-46653 (though the workaround of uninstalling extra JDKs there doesn't work). Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-40439) Move parsers into external library
Title: Message Title Tuukka Mustonen commented on JENKINS-40439 Re: Move parsers into external library Well, Tomas just added mypy (https://github.com/tomasbjerre/violations-lib/issues/13) and pydocstyle (https://github.com/tomasbjerre/violations-lib/issues/12) that are not available in warnings. I have been using custom parsers (via Manage jenkins > Configure system) for those with warnings plugin so I haven't ended up submitting anything... would be nice to have them directly in warnings plugin, of course. I am personally not missing anything else Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-41792) NeoLoad plugin attempts to parse archived XML files
Title: Message Title
Tuukka Mustonen updated an issue
Jenkins / JENKINS-41792
NeoLoad plugin attempts to parse archived XML files
Change By:
Tuukka Mustonen
I am not sure when exactly this happens, but my jenkins.log gets pretty much flooded by something like this:{code}[Fatal Error] dashBoard_*.xml:9:12: Attribute name "_ping" associated with an element type "GET" must be followed by the ' = ' character.Feb 07, 2017 7:55:15 AM com.neotys.nl.controller.report.transform.NeoLoadReportDoc WARNING: Error reading xml file. Attribute name "_ping" associated with an element type "GET" must be followed by the ' = ' character.org.xml.sax.SAXParseException; systemId: file:///var/lib/jenkins/jobs/COSMOS-CI-PERF-ew1-perftest-ping/builds/5/archive/dashBoard_*.xml; lineNumber: 9; columnNumber: 12; Attribute name "_ping" associated with an element type "GET" must be followed by the ' = ' character.at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:257)at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:339)at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:177)at org.jenkinsci.plugins.neoload.integration.supporting.XMLUtilities.readXmlFile(XMLUtilities.java:226)at com.neotys.nl.controller.report.transform.NeoLoadReportDoc.(NeoLoadReportDoc.java:102)at org.jenkinsci.plugins.neoload.integration.ProjectSpecificAction.findXMLResultsFile(ProjectSpecificAction.java:428)at org.jenkinsci.plugins.neoload.integration.ProjectSpecificAction.refreshGraphData(ProjectSpecificAction.java:171)at org.jenkinsci.plugins.neoload.integration.ProjectSpecificAction.(ProjectSpecificAction.java:109)at org.jenkinsci.plugins.neoload.integration.ProjectSpecificActionFactory.createFor(ProjectSpecificActionFactory.java:53)at hudson.model.AbstractProject.createTransientActions(AbstractProject.java:766)at hudson.model.Project.createTransientActions(Project.java:241)at hudson.model.AbstractProject.updateTransientActions(AbstractProject.java:755)at hudson.model.AbstractProject.addProperty(AbstractProject.java:786)at hudson.plugins.disk_usage.DiskUsageUtil.addProperty(DiskUsageUtil.java:58)at hudson.plugins.disk_usage.BuildDiskUsageAction.(BuildDiskUsageAction.java:38)at hudson.plugins.disk_usage.DiskUsageBuildActionFactory.createFor(DiskUsageBuildActionFactory.java:31)at hudson.plugins.disk_usage.DiskUsageBuildActionFactory.createFor(DiskUsageBuildActionFactory.java:21)at hudson.model.Actionable.createFor(Actionable.java:107)at hudson.model.Actionable.getAllActions(Actionable.java:98)at hudson.model.Run.onLoad(Run.java:346)at hudson.model.RunMap.retrieve(RunMap.java:224)at hudson.model.RunMap.retrieve(RunMap.java:56)at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:487)at
[JIRA] (JENKINS-41792) NeoLoad plugin attempts to parse archived XML files
Title: Message Title Tuukka Mustonen created an issue Jenkins / JENKINS-41792 NeoLoad plugin attempts to parse archived XML files Issue Type: Bug Assignee: Unassigned Components: neoload-jenkins Created: 2017/Feb/07 7:58 AM Environment: Jenkins 2.7.4 Neoload plugin 2.0.1 Priority: Minor Reporter: Tuukka Mustonen I am not sure when exactly this happens, but my jenkins.log gets pretty much flooded by something like this: [Fatal Error] dashBoard_*.xml:9:12: Attribute name "_ping" associated with an element type "GET" must be followed by the ' = ' character. Feb 07, 2017 7:55:15 AM com.neotys.nl.controller.report.transform.NeoLoadReportDoc WARNING: Error reading xml file. Attribute name "_ping" associated with an element type "GET" must be followed by the ' = ' character. org.xml.sax.SAXParseException; systemId: file:///var/lib/jenkins/jobs/COSMOS-CI-PERF-ew1-perftest-ping/builds/5/archive/dashBoard_*.xml; lineNumber: 9; columnNumber: 12; Attribute name "_ping" associated with an element type "GET" must be followed by the ' = ' character. at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:257) at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:339) at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:177) at org.jenkinsci.plugins.neoload.integration.supporting.XMLUtilities.readXmlFile(XMLUtilities.java:226) at com.neotys.nl.controller.report.transform.NeoLoadReportDoc.(NeoLoadReportDoc.java:102) at
[JIRA] (JENKINS-27244) Performance plugin archives dashBoard_*.xml
Title: Message Title Tuukka Mustonen commented on JENKINS-27244 Re: Performance plugin archives dashBoard_*.xml Is there a workaround to avoid this? On my Jenkins, I get lots of these in jenkins.log: Feb 07, 2017 7:55:15 AM com.neotys.nl.controller.report.transform.NeoLoadReportDoc WARNING: Error reading xml file. Attribute name "_ping" associated with an element type "GET" must be followed by the ' = ' character. org.xml.sax.SAXParseException; systemId: file:///var/lib/jenkins/jobs/COSMOS-CI-PERF-ew1-perftest-ping/builds/5/archive/dashBoard_*.xml; lineNumber: 9; columnNumber: 12; Attribute name "_ping" associated with an element type "GET" must be followed by the ' = ' character. ...long stacktrace... So, something tries to parse the XML file and because it's invalid XML (or not up to some standard anyway): ... 291 ... I am not sure why Jenkins would try to parse the archived XML file - looks like it's the NeoLoad plugin? But why would it do that? I think I'll open a ticket for them also and link here. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-40439) Move parsers into external library
Title: Message Title Tuukka Mustonen commented on JENKINS-40439 Re: Move parsers into external library Well... unfortunately I think this didn't fly. Should probably be closed? Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-30532) rebuild shuld not store last used password non-stored
Title: Message Title Tuukka Mustonen commented on JENKINS-30532 Re: rebuild shuld not store last used password non-stored Justed bumped into this (on 1.25) and it's a huge security hole that should be patched asap. As a workaround, I ended up disabling rebuilding from those jobs that ask password (via non-stored-password field). Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-40439) Move parsers into external library
Title: Message Title Tuukka Mustonen commented on JENKINS-40439 Re: Move parsers into external library Don't give up just yet - I think it the discussion has been positive and constructive. I feel you both possess great open-minded attitude, it's just natural that you have different matter of taste, but we're getting close! About duplication: If we move the parsers to a separate library then the model needs to be duplicated (and the extension point needs to be replaced by a registry) and after the parsing the model needs to be transformed to the Jenkins model. I don't know the technical details, but I think it's just natural that you need some sort of an adapter that maps each parser into the Jenkins plugin. Yeah, it will add some code (but you shouldn't need to duplicate code). That's the price you must pay for separation of concerns. However, you will collect the benefits later on. Would it be possible to somehow, dynamically resolve and construct these adapters, so that you wouldn't have to explicitly write each? About the dependency libraries: The FindBugs report is tricky, yes. If there is a findbugs-parser ready and working using digester then that, to me, is a valid argument for having digester on the classpath. And use shading to avoid classpath collisions. Sounds good. I'm sure you'll come to terms about dependency libraries if you work on this: use what you need, omit what you don't. You'll start with what you got (minus the Jenkins dependencies), and if Tomas wants less dependencies, I'm sure he's quick to refactor the code. Besides, you can still depend on more dependencies in warnings-plugin. It's just violations-lib that should be minimal. (of course these parsers could use Java 7 classes only, but why should be rewrite working code? Same here, I believe Tomas is a pretty productive guy, so he'll quickly do this Simplifying and working on technical debt every now and then makes sense (although, I don't think this categorizes as "technical debt", but anyway). If you got tests there, it's less likely that things will break. (Just a side note to 3.: the reason for this requirement is from some users having files with thousands of warnings. Parsing these files into a List of warnings in memory is quite slow so using size() on this list will not help. But this is actually not a high priority requirement.) Tell them they should really fix their code I know I'm over-simplifying things but you should "just": 1. Tomas copies/merges the parsers from warnings-plugin into violations-lib. 2. Agree/ensure on the parser API in violations-lib. 3. Ulli switches from built-in parsers into violations-lib. Put whatever you need there, we'll have just single parser implementations in the end, which is the goal of this ticket. You can tune things later on, if need be. Even if steps 2-3 never succeed, there's benefit in step one, as violations-lib will get quite a few parsers that are now missing.
[JIRA] (JENKINS-40439) Move parsers into external library
Title: Message Title Tuukka Mustonen commented on JENKINS-40439 Re: Move parsers into external library I'm not author of anything here, but here's my two cents: 1. I interpret Tomas' statement so that he's not exactly against dependency libraries (that would be weird, as violations-lib is a dependency for other projects). The problem of conflicting requirements versions between multiple libraries is common. I not user of NodeJS, but as I've understood it solves that by having isolated requirements for each library (and also means lots of "wasted" disk space and potentially higher memory consumption... just assuming). In other languages you typically specify minimum version instead of pinning to an exact one. Of course, newer versions may break compatibility, so it's not fool proof, but you can constraint maximum version also. Would that work as a compromise, Tomas Bjerre? I do agree that this library should not depend on jenkins libraries (analysis-core, violations, script-security). In addition to them, there's only commons-digester3 and I don't see it bad (commons and guava libraries are useful, if they cut the amount of code needed, just use them, imo). Other dependencies are test-scope only, and would probably mostly vanish if you get rid of the jenkins-related libraries. 3. Is there a way to obtain only the number of warnings rather than the actual warnings? Can't you just .size() the results? You have to run the full analysis anyway. Maybe I'm missing the point here... Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-40439) Move parsers into external library
Title: Message Title Tuukka Mustonen created an issue Jenkins / JENKINS-40439 Move parsers into external library Issue Type: Improvement Assignee: Ulli Hafner Components: warnings-plugin Created: 2016/Dec/14 9:54 AM Priority: Minor Reporter: Tuukka Mustonen Rather than holding parsers within warnings-plugin, move them to an external library, so that the same parser can be used for multiple plugins. There is https://github.com/tomasbjerre/violations-lib that already duplicates some of the parsers (plus might add a few extra). Would you consider merging the parser logic into that library (and moving it into jenkinsci-organization in Github)? See https://github.com/jenkinsci/violations-plugin/issues/88#issuecomment-266990121. I would assume some sort of a merge would be nice here. Add Comment
[JIRA] (JENKINS-39472) Allow job throttling based on job name regex
Title: Message Title
Tuukka Mustonen updated an issue
Jenkins / JENKINS-39472
Allow job throttling based on job name regex
Change By:
Tuukka Mustonen
When throttling a set of jobs, to avoid having to manage job categories in System Configuration (that I don't necessarily have permissions to access), it would be nice if we could throttle builds by job names.Consider this sequence of jobs:{noformat}PROJECT-buildPROJECT-ENV1-deployPROJECT-ENV1-testPROJECT-ENV2-deployPROJECT-ENV2-testPROJECT-ENV2-perf_test{noformat}I could configure two categories and attach ENV1 and ENV2 jobs to those.However, it would be easier if I could just throttle builds per job name as in:- {{^PROJECT-ENV1-.*$}} for env #1 jobs- {{^PROJECT-ENV2-.*$}} for env #2 jobsThe problems with having to maintain categories is:- Need permissions to {{Manage Jenkins > Configure System}}- Cannot create categories via Job DSL plugin- Maintaining categories is not really needed It's unneeded extra work if you follow sensible naming conventions and use regex
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-39472) Allow job throttling based on job name regex
Title: Message Title Tuukka Mustonen created an issue Jenkins / JENKINS-39472 Allow job throttling based on job name regex Issue Type: New Feature Assignee: Oleg Nenashev Components: throttle-concurrent-builds-plugin Created: 2016/Nov/03 11:16 AM Priority: Minor Reporter: Tuukka Mustonen When throttling a set of jobs, to avoid having to manage job categories in System Configuration (that I don't necessarily have permissions to access), it would be nice if we could throttle builds by job names. Consider this sequence of jobs: PROJECT-build PROJECT-ENV1-deploy PROJECT-ENV1-test PROJECT-ENV2-deploy PROJECT-ENV2-test PROJECT-ENV2-perf_test I could configure two categories and attach ENV1 and ENV2 jobs to those. However, it would be easier if I could just throttle builds per job name as in: ^PROJECT-ENV1-.*$ for env #1 jobs ^PROJECT-ENV2-.*$ for env #2 jobs The problems with having to maintain categories is: Need permissions to Manage Jenkins > Configure System Cannot create categories via Job DSL plugin Maintaining categories is not really needed if you follow sensible naming conventions and use regex
[JIRA] [multijob-plugin] (JENKINS-29424) Ability to filter jobs in multijob view
Title: Message Title Tuukka Mustonen commented on JENKINS-29424 Re: Ability to filter jobs in multijob view +1. Also, combining normal jobs in the same view would be nice. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [core] (JENKINS-11200) Renaming a job does not rename the workspace on slaves
Tuukka Mustonen commented on JENKINS-11200 Renaming a job does not rename the workspace on slaves Seeing this on the latest (v1.515). Jenkins doesn't even delete the workspace on slaves when the job is deleted. It's very easy to reproduce: 1) Create a job named "A" with empty configuration 2) Run the job "A" 3) On slave, find the directory "A" under jenkins/workspace 4) Rename the job "A" to "B" 5) On slave, see that directory "A" is still there and that there is no directory "B" 6) Re-run the job (named as "B" now) 7) On slave, see that a new directory with name of "B" has been created. The old directory "A" is still there as well 8) Delete job "B" 9) On slave, see that both directories "A" and "B" are still there... This is a real issue when jobs are dynamically created and deleted based on branches (http://entagen.github.io/jenkins-build-per-branch/). 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 -- 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/groups/opt_out.
[JIRA] [core] (JENKINS-11200) Renaming a job does not rename the workspace on slaves
Tuukka Mustonen edited a comment on JENKINS-11200 Renaming a job does not rename the workspace on slaves Seeing this on the latest (v1.515). Jenkins doesn't even delete the workspace on slaves when the job is deleted. It's very easy to reproduce: 1) Create a job named "A" with empty configuration 2) Run the job "A" 3) On slave, find the directory "A" under jenkins/workspace 4) Rename the job "A" to "B" 5) On slave, see that directory "A" is still there and that there is no directory "B" 6) Re-run the job (named as "B" now) 7) On slave, see that a new directory with name of "B" has been created. The old directory "A" is still there as well 8) Delete job "B" 9) On slave, see that both directories "A" and "B" are still there... This is a real issue when jobs are dynamically created and deleted based on branches (http://entagen.github.io/jenkins-build-per-branch/) as it causes filesystems of slaves get bloated with workspaces no longer needed. 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 -- 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/groups/opt_out.
[JIRA] (JENKINS-8783) Renamin promotion process doesn't remove the original promotion process
Tuukka Mustonen commented on JENKINS-8783 Renamin promotion process doesnt remove the original promotion process This doesn't reproduce anymore with Jenkins v1.488 and promoted-builds-plugin v2.8. It's probably a duplicate of JENKINS-12799 which has been fixed in v2.8? 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-7666) ClassCastException parsing JUnit result
Tuukka Mustonen commented on JENKINS-7666 ClassCastException parsing JUnit result I just bumped into this when I changed a free-style job into native maven-job. Note: I didn't convert the job because it's not possible, simply created a new job with same configuration. I don't have "Publish Findbugs analysis results" enabled and the build still fails to the ClassCastException. 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-10502) Add an option to make archiving the artifacts non-fatal if they don't exist
[
https://issues.jenkins-ci.org/browse/JENKINS-10502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163040#comment-163040
]
Tuukka Mustonen commented on JENKINS-10502:
---
Same problem here. I set the {{hudson.tasks.ArtifactArchiver.warnOnEmpty}} to
/etc/default/jenkins (came with jenkins debian-package) and seems to work.
Still, optional checkbox in job configuration would be nice.
Add an option to make archiving the artifacts non-fatal if they don't exist
---
Key: JENKINS-10502
URL: https://issues.jenkins-ci.org/browse/JENKINS-10502
Project: Jenkins
Issue Type: Improvement
Components: core
Environment: Jenkins 1.421
Reporter: Thomas Fields
If you tick the box to enable Archive the artifacts, populate the Files to
archive, and your build fails to output those artifacts it will fail with
something like this:
{code}
12:11:51 Archiving artifacts
12:11:51 ERROR: No artifacts found that match the file pattern
tfields/Live/Engine/Tools/Layout.*. Configuration error?
12:11:57 ERROR: 'tfields/Live/Engine/Tools/Layout.*' doesn't match anything:
'tfields' exists but not 'tfields/Live/Engine/Tools/Layout.*'
12:11:57 Build step 'Archive the artifacts' changed build result to FAILURE
{code}
Depending on what your build actually does, those artifacts might not always
be created. I'd like to propose that you add an option to make the archiving
of artifacts non fatal.
Thanks,
Tom.
--
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
[JIRA] (JENKINS-10502) Add an option to make archiving the artifacts non-fatal if they don't exist
[
https://issues.jenkins-ci.org/browse/JENKINS-10502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163040#comment-163040
]
Tuukka Mustonen edited comment on JENKINS-10502 at 5/21/12 5:29 PM:
Same problem here. I set the {{hudson.tasks.ArtifactArchiver.warnOnEmpty}} to
{{/etc/default/jenkins}} (came with jenkins debian-package) and it seems to
work.
Still, optional checkbox in job configuration would be nice.
was (Author: tuukkamustonen):
Same problem here. I set the {{hudson.tasks.ArtifactArchiver.warnOnEmpty}}
to /etc/default/jenkins (came with jenkins debian-package) and seems to work.
Still, optional checkbox in job configuration would be nice.
Add an option to make archiving the artifacts non-fatal if they don't exist
---
Key: JENKINS-10502
URL: https://issues.jenkins-ci.org/browse/JENKINS-10502
Project: Jenkins
Issue Type: Improvement
Components: core
Environment: Jenkins 1.421
Reporter: Thomas Fields
If you tick the box to enable Archive the artifacts, populate the Files to
archive, and your build fails to output those artifacts it will fail with
something like this:
{code}
12:11:51 Archiving artifacts
12:11:51 ERROR: No artifacts found that match the file pattern
tfields/Live/Engine/Tools/Layout.*. Configuration error?
12:11:57 ERROR: 'tfields/Live/Engine/Tools/Layout.*' doesn't match anything:
'tfields' exists but not 'tfields/Live/Engine/Tools/Layout.*'
12:11:57 Build step 'Archive the artifacts' changed build result to FAILURE
{code}
Depending on what your build actually does, those artifacts might not always
be created. I'd like to propose that you add an option to make the archiving
of artifacts non fatal.
Thanks,
Tom.
--
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
[JIRA] (JENKINS-13852) Allow speciying Git SHA1 commit id for next build(s) as Predefined parameter
Tuukka Mustonen created JENKINS-13852: - Summary: Allow speciying Git SHA1 commit id for next build(s) as Predefined parameter Key: JENKINS-13852 URL: https://issues.jenkins-ci.org/browse/JENKINS-13852 Project: Jenkins Issue Type: Improvement Components: git-parameter, parameterized-trigger Reporter: Tuukka Mustonen Assignee: huybrechts Consider a stream of jobs: A - B - C We can parameterize to build B with the same git commit SHA1 as A by adding Pass-through Git commit that was build parameter in A. However, this only works for subsequent jobs. There is no way to configure what SHA1 C will use. In our case, the B uses a different Git repository than A, while C again uses the same repository as A. We would need to parameterize the stream so that A and C use the same revision. I tried manually setting GIT_COMMIT variable through Predefined parameters in A. Using 'env' as a shell script in B, I can see that GIT_COMMIT environment property gets correctly set, however, it doesn't seem to have any effect. Maybe this is because parameters kick in only after Git checkout, so that the default (empty) GIT_COMMIT is used for checkout and GIT_COMMIT is only set to what was passed after that. Anyway, would be nice to be able to manually set the GIT_COMMIT through Predefined parameters instead of having to use the Pass-through Git commit that was build. I think that be quite flexible solution. -- 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
