[JENKINS-34547] Switch WorkflowJob.concurrentBuild to JobProperty #8

abayer · 2016-07-12T17:27:17Z

JENKINS-34547

First attempt at implementation.
Tests written - see [JENKINS-34547] Test for WorkflowConcurrentBuildJobProperty. workflow-multibranch-plugin#19
Verify backwards compatibility.
Verify UI works as expected.

cc @reviewbybees most especially @jglick

First work - tests still to come.

abayer · 2016-07-12T17:58:12Z

Hmm - looks like JobPropertyStep may need to be moved into here for test purposes, at least.

abayer · 2016-07-12T18:04:47Z

Or the test needs to go in workflow-multibranch-plugin.git...

jglick · 2016-07-12T18:24:17Z

...n/java/org/jenkinsci/plugins/workflow/job/properties/WorkflowConcurrentBuildJobProperty.java

+    }
+
+    @Extension
+    @Symbol("concurrentBuildProperty")


🐛 do not include property in the symbol name. It is implicit in the extension point.

Okiedokie - I was wary of just going with "concurrentBuild" since this is Pipeline-specific...

jglick · 2016-07-12T18:31:19Z

src/main/java/org/jenkinsci/plugins/workflow/job/WorkflowJob.java

    }

    public void setConcurrentBuild(boolean b) throws IOException {
-        concurrentBuild = b ? null : false;


I think you now need to unconditionally set concurrentBuild to null. And deprecate this method.

Either way, you should start off by writing the @LocalData-based tests which define what you expect to happen w.r.t. settings compatibility.

Ok, will do.

abayer · 2016-07-12T19:13:22Z

src/main/java/org/jenkinsci/plugins/workflow/job/WorkflowJob.java

@@ -138,6 +140,9 @@ public WorkflowJob(ItemGroup parent, String name) {
        for (Trigger t : triggers) {
            t.start(this, Items.currentlyUpdatingByXml());
        }
+        if (concurrentBuild != null) {


Not happy about this, but setConcurrentBuild(boolean) alone wasn't enough to get the migration working.

jglick · 2016-07-12T23:05:12Z

Need to use configRoundTrip to see that the property can be saved & redisplayed on a non-multibranch project.

abayer · 2016-07-12T23:18:44Z

@jglick - clarifying - you mean just a JenkinsRule.configRoundTrip(job)?

abayer · 2016-07-13T01:30:15Z

So the OptionalJobProperty approach has actually broken this logic pretty hard - need to do some reworking.

abayer · 2016-07-13T01:39:40Z

There's a nasty little contradiction - if we want just a checkbox in the UI, we need OptionalJobProperty, but if we want to have concurrent builds enabled by default with a way to disable them from the properties step, OptionalJobProperty doesn't work. Grr.

Having an OptionalJobProperty used solely as a boolean, effectively, means we need to have the default case be in effect when the property doesn't exist. That's different than the traditional concurrent build check, where the default is to not allow concurrent builds. Since we do want concurrent builds by default in Pipeline jobs, we need to instead have the property be for *disabling* concurrent builds. So...yeah. Not sure yet how to do a UI config test for an OptionalJobProperty - need to work on that.

jglick · 2016-07-13T02:01:39Z

you mean just a JenkinsRule.configRoundTrip(job)

Yes.

if we want to have concurrent builds enabled by default

No strong opinion. Originally this was the only option for Pipeline. But for freestyle projects, the default has always been nonconcurrent, with the option for concurrent added later. Certainly we need to preserve the behavior of existing jobs.

with a way to disable them from the properties step, OptionalJobProperty doesn't work

Why is that?

jglick · 2016-07-13T02:34:04Z

src/main/java/org/jenkinsci/plugins/workflow/job/WorkflowJob.java

@@ -138,6 +140,9 @@ public WorkflowJob(ItemGroup parent, String name) {
        for (Trigger t : triggers) {
            t.start(this, Items.currentlyUpdatingByXml());
        }
+        if (concurrentBuild != null && !concurrentBuild) {


🐜 Do you not want to call setConcurrentBuild even if it is false, just in case? Otherwise a true value will stick around in config.xml indefinitely. We would like to unconditionally delete the deprecated field.

Yeah, you're right there. That was an artifact of earlier efforts. Fixing!

jglick · 2016-07-13T02:44:24Z

🐝

jglick · 2016-07-13T02:47:18Z

if we want to have concurrent builds enabled by default
No strong opinion.

Though I tend to prefer concurrent by default, since to my way of thinking the serial option is a special behavior, akin to a QueueTaskDispatcher which blocks builds from running under some conditions (example)—in this case, just that another build of the same job is currently running.

abayer · 2016-07-13T14:28:51Z

So given that the default behavior has been to allow concurrent builds, I think that has to stay the same. Therefore, switching the UI from a checked-by-default checkbox for enabling concurrent builds to an unchecked-by-default checkbox for disabling concurrent builds seems eminently reasonable for me.

jglick · 2016-07-13T14:44:39Z

given that the default behavior has been to allow concurrent builds, I think that has to stay the same

Well…not for jobs saved since the concurrentBuild field was added. But for really old jobs last saved before there was even the option, yes.

switching the UI from a checked-by-default checkbox for enabling concurrent builds to an unchecked-by-default checkbox for disabling concurrent builds seems eminently reasonable for me

I am not opposed to that necessarily, though users might be confused that the UI is opposite that of freestyle projects. If we want to keep a consistent UI then we cannot use OptionalJobProperty, I am afraid.

jglick · 2016-07-13T14:46:00Z

src/main/java/org/jenkinsci/plugins/workflow/job/WorkflowJob.java

-            if (!b) {
-                addProperty(new DisableConcurrentBuildsJobProperty());
+
+        boolean propertyExists = getProperty(DisableConcurrentBuildsJobProperty.class) == null;


🐜 the variable name is the opposite of the meaning.

Also the comment was the inverse of what was actually being done. Whoops!

abayer · 2016-07-13T15:18:13Z

Yeah, the UI inconsistency is the only way I see to have just a checkbox with no further config in the UI, where it can also be disabled via the properties step. Not to mention there's a challenge in getting an OptionalJobProperty to be selected by default!

jglick · 2016-07-13T15:40:33Z

the UI inconsistency is the only way I see to have just a checkbox with no further config in the UI, where it can also be disabled via the properties step

Well the alternative is a non-Optional JobProperty whose config view has a checkbox in it (checked by default), and from Jenkinsfile you would need to write something like

properties([concurrentBuilds(false)])

In some ways this is a little cleaner since it is apparent which jobs have been updated to the new format: all newly saved jobs should have the property.

jglick · 2016-07-13T15:41:36Z

re:bee:

abayer · 2016-07-13T15:50:51Z

Yeah, I considered the traditional JobProperty approach but dislike that UX more than changing the behavior.

svanoort · 2016-07-13T19:04:45Z

src/main/java/org/jenkinsci/plugins/workflow/job/WorkflowJob.java

+                }
+                bc.commit();
+            } finally {
+                bc.abort();


Why are we aborting after committing when successful?

That was lifted from somewhere - lemme find it. I think that the abort ends up doing nothing post-commit....

Ah, this was the paradigm used before jenkinsci/jenkins@5b4dbb3, and since we're not basing on HEAD of core, we still need to do things the old way.

I mean yeah it shouldn't, but it's odd to me to do it there rather than an abort and re-throw on error.

I'm assuming that the paradigm is saying "Eh, if it goes wrong, just don't do it and move on"?

I'd say the real issue isn't the code path - it's the name abort, since what it really should be is something like cleanup since it only aborts if the change is incomplete. Anyway, after that commit I linked above, it's irrelevant.

Although... the alternative is pretty ugly (catch Exception, try to abort, then finally rethrow exception?).

Meh. 🐝 and some grumping about the BulkChange APIs from me.

The code is correct here.

abayer · 2016-07-13T19:23:59Z

Yay, @reviewbybees done

[JENKINS-34547] Switch WorkflowJob.concurrentBuild to JobProperty

c306b2f

First work - tests still to come.

abayer added the work-in-progress label Jul 12, 2016

Add symbol, rename field.

b43f829

jglick reviewed Jul 12, 2016
View reviewed changes

abayer mentioned this pull request Jul 12, 2016

[JENKINS-34547] Test for WorkflowConcurrentBuildJobProperty. jenkinsci/workflow-multibranch-plugin#19

Merged

jglick reviewed Jul 12, 2016
View reviewed changes

abayer added 2 commits July 12, 2016 11:39

Addressing review comments

71277a7

Properly handle and test settings migration.

4fb0624

abayer reviewed Jul 12, 2016
View reviewed changes

jglick reviewed Jul 13, 2016
View reviewed changes

Review comments, moving tests around, adding round trip test

c563ecb

jglick reviewed Jul 13, 2016
View reviewed changes

Clarifying propertyExists

3b58a34

svanoort reviewed Jul 13, 2016
View reviewed changes

jglick removed the work-in-progress label Jul 13, 2016

jglick merged commit d2962d1 into jenkinsci:master Jul 13, 2016

basil mentioned this pull request Jul 16, 2019

Deprecate support for concurrentBuild in Pipeline jobs jenkinsci/job-dsl-plugin#1189

Merged

[JENKINS-34547] Switch WorkflowJob.concurrentBuild to JobProperty #8

[JENKINS-34547] Switch WorkflowJob.concurrentBuild to JobProperty #8

Conversation

abayer commented Jul 12, 2016 • edited Loading

abayer commented Jul 12, 2016

abayer commented Jul 12, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jglick commented Jul 12, 2016

abayer commented Jul 12, 2016

abayer commented Jul 13, 2016

abayer commented Jul 13, 2016

jglick commented Jul 13, 2016

jglick Jul 13, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jglick commented Jul 13, 2016

jglick commented Jul 13, 2016

abayer commented Jul 13, 2016

jglick commented Jul 13, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

abayer commented Jul 13, 2016

jglick commented Jul 13, 2016 • edited Loading

jglick commented Jul 13, 2016

abayer commented Jul 13, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

abayer commented Jul 13, 2016

abayer commented Jul 12, 2016 •

edited

Loading

jglick Jul 13, 2016 •

edited

Loading

jglick commented Jul 13, 2016 •

edited

Loading