[JIRA] (JENKINS-60613) Cannot use Jenkins variable to override Release Number after plugin upgrade to 3.0

0 views
Skip to first unread message

jstarbird@scisolutions.com (JIRA)

unread,
Dec 30, 2019, 11:42:02 AM12/30/19
to jenkinsc...@googlegroups.com
Jon Starbird created an issue
 
Jenkins / Bug JENKINS-60613
Cannot use Jenkins variable to override Release Number after plugin upgrade to 3.0
Issue Type: Bug Bug
Assignee: Andrew Sumner
Components: inedo-buildmaster-plugin
Created: 2019-12-30 16:41
Environment: Jenkins 2.204.1
BuildMaster plugin 3.0.0
Priority: Critical Critical
Reporter: Jon Starbird

After upgrading to 3.0 of the plugin I can no longer specify the Release Number with a variable as I could before in the Create Build and Deploy Build tasks.
This in the classic Jenkins job mode.

We run multiple release builds simultaneously at times so I need to be able to specify it via a variable otherwise we have to have have extra jobs and hard code the release number as we cannot use Latest Active Release. 

Having the ability to override it in the both tasks or even better would be to have the override in the Inject BuildMaster release details step that would then set the buildmaster_release_number variable for the other BM tasks.

I have not tried yet in declarative script mode yet but this would be needed there as well. 

I am going to have to downgrade to the older 2.4.0 version of the plugin for now but I don't know if that version will work with BuildMaster 6.2 when it comes out. 
Add Comment Add Comment
 
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo

andrew.sumner@xtra.co.nz (JIRA)

unread,
Dec 30, 2019, 8:16:02 PM12/30/19
to jenkinsc...@googlegroups.com
Andrew Sumner commented on Bug JENKINS-60613
 
Re: Cannot use Jenkins variable to override Release Number after plugin upgrade to 3.0

Ah, you're correct - I haven't catered for custom variables.  I was assuming that people would just use the ones injected from the environment or parameter tasks.

I had a quick look at using the combobox jelly tag instead of the select option, I don't like how this behaves so will take a little longer to get this working how I would like it - eta a couple of days.

What is the source for the variable that holds the release number? There might be a way I can better support your use case.  For example the plugin now supports a BuildMaster Parameter task that allows you to select a release a build time.

Alternatively you could ignore the environment task altogether and inject your own variables:

  1. "BUILDMASTER_APPLICATION_ID" - can contain either the id or application name
  2. "BUILDMASTER_RELEASE_NUMBER" - set that to the desired release number

Ignoring this issue, are there any other features you'd like to see in this plugin?

jstarbird@scisolutions.com (JIRA)

unread,
Dec 30, 2019, 8:23:03 PM12/30/19
to jenkinsc...@googlegroups.com

I hadn't realized you had added the job param option. That actually might do the trick. 

That or the env vars as you mentioned would also solve the issue, just didn't occur to me to do that. 

as to other new features, nothing I can currently think of. 

Thanks!

andrew.sumner@xtra.co.nz (JIRA)

unread,
Dec 30, 2019, 11:57:05 PM12/30/19
to jenkinsc...@googlegroups.com

Let me know how it goes. If it’s going to be easier for you I’m happy to get a patch out, otherwise I’ll leave it as is for now.

andrew.sumner@xtra.co.nz (JIRA)

unread,
Dec 31, 2019, 12:02:02 AM12/31/19
to jenkinsc...@googlegroups.com

Updated wiki is at https://plugins.jenkins.io/inedo-buildmaster, this describes the release parameter, changes to variable names, etc.

jstarbird@scisolutions.com (JIRA)

unread,
Dec 31, 2019, 11:18:03 AM12/31/19
to jenkinsc...@googlegroups.com

Using the Env vars as build params is what is going to really work. This will allow me to use only 1 or 2 deployment jobs for all the apps instead of having to use one for each app. 

Not sure if you could make the BM parameter to have two inputs to allow the app and release number to be selected/defined at run time.  You can just define string var params for them but having the app list pre-populated would just help to ensure users put the right values in. But this only applies to being able to have a single Deployment Jobs in Jenkins that would allow you to start a deployment. 

andrew.sumner@xtra.co.nz (JIRA)

unread,
Dec 31, 2019, 6:47:03 PM12/31/19
to jenkinsc...@googlegroups.com

Just to make sure I'm heading down the right track:

You would like the BM Release Parameter to have the option of selecting both the app and release at build time. This should be doable.

Does this solve the "env vars as build params" from the first paragraph, or do you mean you still need the ability to to enter a custom variable into the task config's app & release options instead of just the options I have provided in the list?

 

 

 

jstarbird@scisolutions.com (JIRA)

unread,
Dec 31, 2019, 6:54:02 PM12/31/19
to jenkinsc...@googlegroups.com

Yes, having it allow selecting both. 

The options you listed provide the right method to do it so, no, I don't think there is a need to allow using custom variables in the Create Build or Deploy Build tasks.

Thanks.

andrew.sumner@xtra.co.nz (JIRA)

unread,
Jan 4, 2020, 7:59:02 PM1/4/20
to jenkinsc...@googlegroups.com
Andrew Sumner updated an issue
 
Change By: Andrew Sumner
Attachment: Select Application and Release.docx

andrew.sumner@xtra.co.nz (JIRA)

unread,
Jan 4, 2020, 8:02:02 PM1/4/20
to jenkinsc...@googlegroups.com
Andrew Sumner commented on Bug JENKINS-60613
 
Re: Cannot use Jenkins variable to override Release Number after plugin upgrade to 3.0

Adding reactive parameters turned out to be a LOT harder than I anticipated, so I've taken a different tack and used the [active choices plugin|https://plugins.jenkins.io/uno-choice.] 

I've documented this in the attached word document.  You can either store the groovy code using the [scriptler|https://plugins.jenkins.io/scriptler []|https://plugins.jenkins.io/uno-choice].] plugin, or directly in the job with the active choice plugin.

Select Application and Release.docx

andrew.sumner@xtra.co.nz (JIRA)

unread,
Jan 4, 2020, 8:03:01 PM1/4/20
to jenkinsc...@googlegroups.com

Let me know how this works for you.

jstarbird@scisolutions.com (JIRA)

unread,
Jan 6, 2020, 1:23:02 PM1/6/20
to jenkinsc...@googlegroups.com

I sort of thought doing that might prove difficult. It's solvable in other ways so it really is not a big deal.

I had used that plugin before on an older server but I had to drop it as it ended up causing the server to become corrupted, or rather the scriptler portion. I never used the scriptler portion but it eventually made it so the Jenkins server could not be upgraded. I never had a chance to dig real deep into it.

Then with Scriptler is of course a security issue plugin which here I cannot risk using. 

Anyway, thanks for spending the time to look into it. 

Have a great year!

andrew.sumner@xtra.co.nz (JIRA)

unread,
Jan 6, 2020, 8:15:02 PM1/6/20
to jenkinsc...@googlegroups.com

I haven't given up yet, there is one more thing I want to try .

Scriptler is an optional component, it can all be done within the active choice plugin.  Scriptler was just a little tidier which is why I documented that approach.

 

andrew.sumner@xtra.co.nz (JIRA)

unread,
Jan 8, 2020, 8:50:02 AM1/8/20
to jenkinsc...@googlegroups.com

Good news, I've finally got this working. The solution ended up being rather simple - around 20 lines of code. Shame the Jenkins documentation is garbage, it should have been much easier to get this up and running.  

I've got a bit more testing to do but should have a new release out in the next few days.

jstarbird@scisolutions.com (JIRA)

unread,
Jan 8, 2020, 1:48:03 PM1/8/20
to jenkinsc...@googlegroups.com

Great. I'll keep an eye out for it.  Thanks!

andrew.sumner@xtra.co.nz (JIRA)

unread,
Jan 12, 2020, 5:17:03 AM1/12/20
to jenkinsc...@googlegroups.com

I've released version 3.1 to support this. Let me know how it goes. As a first cut the cascading dropdown was easier to implement as a single parameter with two dropdowns, so let me know how this goes - and whether you need a build number dropdown as well.

I would still like to seperate this out into seperate parameters and get a similar behviour to active choices so depending on time constraints I will continue to play with this.

jstarbird@scisolutions.com (JIRA)

unread,
Jan 13, 2020, 1:12:03 PM1/13/20
to jenkinsc...@googlegroups.com

Put on my test server, works great. Not sure you need to do it any differently but up to you. 

Thank you!

andrew.sumner@xtra.co.nz (JIRA)

unread,
Jan 24, 2020, 10:12:02 PM1/24/20
to jenkinsc...@googlegroups.com

I've got this working with seperate parameters and even support builds as well as application and release. I've got this sitting in a seperate branch and I'm not planning on releasing it for the moment unless anyone asks for it, so if you ever want to move in that direction let me know

jstarbird@scisolutions.com (JIRA)

unread,
Jan 28, 2020, 11:01:03 AM1/28/20
to jenkinsc...@googlegroups.com

actually that would be great. just the other day I was thinking about asking if selecting builds would be possible but it wasn't a critical thing

andrew.sumner@xtra.co.nz (JIRA)

unread,
Feb 25, 2020, 3:50:02 PM2/25/20
to jenkinsc...@googlegroups.com

Just to let you know - I haven't forgotten about this. I am in the process of moving house so I haven't had much spare time lately. This change is ready to go.

However... the BuildMaster 6.2.5 release has a bug in one of the APIs used by the "wait for build to complete" option. There where a couple of other minor changes to the API but those were easily fixed. As soon as I have a fix for this I will be getting a new version out.

jstarbird@scisolutions.com (JIRA)

unread,
Feb 25, 2020, 3:53:03 PM2/25/20
to jenkinsc...@googlegroups.com

No worries. I'm not ready to move to 6.2.x of BM yet anyway. 

thanks for the update. Good luck with the move.
Reply all
Reply to author
Forward
0 new messages