[JIRA] [rtc] (JENKINS-21964) Build definition and workspace name should accept parameters and/or environment variables.

36 views
Skip to first unread message

griffman99h@gmail.com (JIRA)

unread,
Feb 26, 2014, 11:49:00 AM2/26/14
to jenkinsc...@googlegroups.com
Issue Type: Improvement Improvement
Assignee: Deluan Quintão
Components: rtc, teamconcert
Created: 26/Feb/14 4:47 PM
Description:

We are looking to use the same build project for multiple streams in rtc (parallel supported versioning). Currently if you try to add a parameter or variable to the build definition name or repository workspace name, the team concert plugin will not parse the variable and error out, not finding the correct definition/workspace. for example

parameter choice list :
stream = ver2.5, ver3.2, ver6.0

build definition = jenkins.$stream

adding this functionality would allow us to greatly expand our use of jenkins for production builds as well as testing processes for individual developer workspaces. Currently we are considering this a blocker for set up of developer testing.

the only know method around this is to set up a template project using another plugin.

Project: Jenkins
Priority: Major Major
Reporter: James Griffin
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

heatherf@ca.ibm.com (JIRA)

unread,
Feb 28, 2014, 5:59:58 AM2/28/14
to jenkinsc...@googlegroups.com
Heather Fraser-Dube assigned Improvement JENKINS-21964 to Unassigned
Change By: Heather Fraser-Dube (28/Feb/14 10:58 AM)
Assignee: Deluan Quintão

heatherf@ca.ibm.com (JIRA)

unread,
Feb 28, 2014, 6:03:58 AM2/28/14
to jenkinsc...@googlegroups.com

Another option would be use the Hudson/Jenkins integration provided by RTC. There you could set up a build definition that references your Jenkins build. When requesting a build of the rtc build definition you can pick the workspace you want built.

griffman99h@gmail.com (JIRA)

unread,
Mar 3, 2014, 12:49:58 PM3/3/14
to jenkinsc...@googlegroups.com

we are using the build definition and jenkins integration in RTC. we have multiple streams which need to have separate build definitions for each stream. what I am asking is for the build definition field in jenkins to handle parameters so we can use the same jenkins project and choose the stream/build definition on the same project. otherwise we need separate projects for each build definition.

heatherf@ca.ibm.com (JIRA)

unread,
Mar 26, 2014, 11:26:04 AM3/26/14
to jenkinsc...@googlegroups.com

If substitution can be done on the build definition/workspace name, what would be the expectation wrt polling? Or are these builds triggered by other builds?

heatherf@ca.ibm.com (JIRA)

unread,
Mar 26, 2014, 11:37:04 AM3/26/14
to jenkinsc...@googlegroups.com

griffman99h@gmail.com (JIRA)

unread,
Mar 27, 2014, 10:23:04 AM3/27/14
to jenkinsc...@googlegroups.com

these would have to be launched by a unique build project to handle the scheduler and polling. but having the substitution for definition/workspace will still allow us to cut down on the rest of the project chain. going forward, this will allow our new release process to be limited to "create new definition + create new scheduler". All other build steps remain the same. At roughly 5-10 new releases a month that is a major performance gain for manual work.

lorelei.mccollum@gmail.com (JIRA)

unread,
Jul 9, 2014, 8:08:07 PM7/9/14
to jenkinsc...@googlegroups.com

I would also like this functionality, it would be nice to be able to have a build with paramaters, where you pass in your credentials and the workspace and it would then build it

heatherf@ca.ibm.com (JIRA)

unread,
Jul 10, 2014, 9:11:05 AM7/10/14
to jenkinsc...@googlegroups.com

Lorelei can you describe how you would be using this. Would it be for users running their own personal build or would it be triggered another way?

lorelei.mccollum@gmail.com (JIRA)

unread,
Jul 10, 2014, 9:25:07 AM7/10/14
to jenkinsc...@googlegroups.com

Yeah I would like users to be able to build their own stream, and then have a pre submission pipeline run against it, so it would do things like deploy that build, test it, report out on it etc.. but I would want it to be that persons own Stream or workspace... so they can test it out before delivering back to the main trunk - does that make sense?

Reply all
Reply to author
Forward
0 new messages