[JENKINS-26010] Workflow compatibility #240

tfennelly · 2015-07-10T13:53:55Z

Current status: Ready for review. No more changes planned.

rsandell · 2015-07-10T14:04:27Z

...com/sonyericsson/hudson/plugins/gerrit/trigger/dependency/DependencyQueueTaskDispatcher.java

@@ -118,7 +118,7 @@ public static DependencyQueueTaskDispatcher getInstance() {
    @Override
    public CauseOfBlockage canRun(Queue.Item item) {
        //AbstractProject check
-        if (!(item.task instanceof AbstractProject)) {
+        if (!(item.task instanceof Job)) {
            logger.debug("Not an abstract project: {}", item.task);


The log is a lie :)

rsandell · 2015-07-10T14:43:37Z

@scoheb, @GLundh, @TWestling I'm going on vacation today, so I won't be much help to @tfennelly during that time. Could you help him out with some friendly review?

GLundh · 2015-07-10T14:47:25Z

@rsandell: I would love to help out, but I'm going on vacation myself today, and wont be able to spend much time on it until early august.

scoheb · 2015-07-10T14:51:00Z

@rsandell ... I can definitely lend a hand!

jacob-keller · 2015-07-10T15:14:43Z

@tfennelly I'm willing to attempt running a version as well, to see how it goes. Let me know what I can do to help. Thanks for taking a serious stab at this one.

tfennelly · 2015-07-10T15:21:45Z

@scoheb @GLundh @jacob-keller Thanks guys 🍺 ... I'll ping ye as soon as I have something testable.

rsandell · 2015-07-10T16:14:45Z

src/main/java/com/sonyericsson/hudson/plugins/gerrit/trigger/hudsontrigger/EventListener.java

-        } else if (project.getHasCustomQuietPeriod()
-                && project.getQuietPeriod() > projectbuildDelay) {
-            projectbuildDelay = project.getQuietPeriod();
+        } else if (project instanceof AbstractProject) {


ParameterizedJobMixing.ParameterizedJob which both AbstractProject and Workflow implements has quietPeriod methods IIRC.

Rights, but it doesn't have AbstractProject.getHasCustomQuietPeriod. We'd have to drop that. Would that be a terrible thing and cause regressions?

Note getQuietPeriod defaults if not set.

I personally don't think that's an issue.
On Jul 10, 2015 9:42 AM, "Tom Fennelly" notifications@github.com wrote:

In
src/main/java/com/sonyericsson/hudson/plugins/gerrit/trigger/hudsontrigger/EventListener.java
#240 (comment)
:

BadgeAction badgeAction = new BadgeAction(event); //during low traffic we still don't want to spam Gerrit, 3 is a nice number, isn't it? int projectbuildDelay = t.getBuildScheduleDelay(); if (cause instanceof GerritUserCause) { // it's a manual trigger, no need for a quiet period projectbuildDelay = 0;

} else if (project.getHasCustomQuietPeriod()

&& project.getQuietPeriod() > projectbuildDelay) {

projectbuildDelay = project.getQuietPeriod();

} else if (project instanceof AbstractProject) {

Note getQuietPeriod defaults if not set.

—
Reply to this email directly or view it on GitHub
https://github.com/jenkinsci/gerrit-trigger-plugin/pull/240/files#r34372420
.

If not check AbstractProject.getHasCustomQuietPeriod, ParameterizedJob.getQuietPeriod might return system value given by Jenkins.getQuietPeriod if quietPeriod in project is not set. system's default is 5.

BTW, can we use GT's own period only?

So, if I understand this right, the old behavior was something like:

If we're manual trigger, don't delay at all

If the job has a custom quiet period (ie: not default) AND that period is larger than the ScheduleDelay, use this

Otherwise, use the ScheduleDelay

So what's wrong with using the quietPeriodDelay even if it's not customized? Why can't we also check if we're above the default?

Is it so that GT's custom delay overrides the global default, but not per-jobs?

I'd rather use the longest of all configured delays, not the shortest. Ie: GT's delay only overrides global if the global is shorter?

We could also use only GT's trigger period, without worrying about per-job settings?

Thoughts?

@jacob-keller @rinrinne guys, I'm afraid I don't really have a valuable opinion on stuff like this. I will be relying on ye to tell me what makes most sense from a Gerrit pov.

rsandell · 2015-07-10T16:24:38Z

src/main/java/com/sonyericsson/hudson/plugins/gerrit/trigger/hudsontrigger/GerritTrigger.java

@@ -1918,8 +1928,12 @@ public synchronized void scheduled(ChangeBasedEvent event, ParametersAction para
         *            The event that originally triggered the build.
         */
        private void cancelJob(GerritTriggeredEvent event) {
+            if (!(job instanceof Queue.Task)) {
+                logger.error("Error canceling job. The job is not of type Task.");
+            }


I guess you should return directly after the logging?

And please log the task as well, so the admin knows which of the 10k jobs the log is talking about :)

rsandell · 2015-07-10T16:29:17Z

@scoheb @jacob-keller Thanks guys! Then @tfennelly is in good hands while I relax with some 🍻 myself :)

amuniz · 2015-07-10T17:24:47Z

src/main/java/com/sonyericsson/hudson/plugins/gerrit/trigger/GerritServer.java

+
+            // TODO: find a way to handle add/remove of triggers
+            if (!(job instanceof AbstractProject)) {
+                return;


What would happen if it's an instance of WorkflowJob?

Does WorkflowJob have a way to add and remove triggers? I assume we'd want something similar to that? I know that the ParameterizedJobMixin does not have support for add triggers, but maybe we can just instanceOf to WorkflowJob here?

According to the source for WorkflowJob.java, it appears that WorkflowJob has an "addTrigger" function and getTriggers function, but this isn't exposed by the Mixin API. It would feel really awkward to instanceof and then use the same code both times.... Also, it doesn't support "getTrigger" standalone only the getTriggers...

Kind of ugly either way.

The getTriggers() method is defined in ParameterizedJobMixIn.ParameterizedJob. We can cast to this one better than WorkflowJob.

@amuniz At the moment, nothing will happen for a Workflow Job i.e. add/remove of triggers is not supported for workflow as things stand. That's why I marked it with a TODO. We need to find a way of handling it for workflow. AbstractProject has methods for adding and removing triggers, but that's no help for a Workflow job.

Trigger rename might be fixable by finding the current trigger and renaming the server on it Vs removing and readding the trigger (at the moment, rename is supported by removing the trigger and adding a new one). Not sure yet how remove will be supported (when a Gerrit server is removed we need to find all Jobs with triggers for that server and remove them).

you can add a trigger easily. It seems like the trigger add code will remove the old trigger already. Sadly WorkflowJob.java does not export a remove trigger function like the code does. Maybe we just don't bother removing the old trigger at all when a server is removed?

What's the reason that we actually have remove/add trigger code here specifically? I presume to prevent a bug? What do other trigger plugins do to prevent this sort of issue?

Auto removing zombie triggers after a Gerrit server is removed seems to make sense to me.

In any case (and imo), the debate on the pros and cons of programmatically removing a trigger is something that should happen separate to this PR. IMO, our job here is to integrate workflow and maintain the same feature set. It shouldn't be about proposing fundamental plugin design changes.

On Jul 27, 2015 12:48 AM, "Tom Fennelly" notifications@github.com wrote:

In
src/main/java/com/sonyericsson/hudson/plugins/gerrit/trigger/GerritServer.java:

@@ -914,14 +915,21 @@ private void rename(String newName) {
* @param oldName the old name of the Gerrit server
*/
private void changeSelectedServerInJobs(String oldName) {

for (AbstractProject job :
PluginImpl.getConfiguredJobs_(oldName)) {

GerritTrigger trigger =
(GerritTrigger)job.getTrigger(GerritTrigger.class);

for (Job job : PluginImpl.getConfiguredJobs_(oldName)) {

// TODO: find a way to handle add/remove of triggers

if (!(job instanceof AbstractProject)) {

return;

Auto removing zombie triggers after a Gerrit server is removed seems to
make sense to me.

In any case (and imo), the debate on the pros and cons of
programmatically removing a trigger is something that should happen
separate to this PR. IMO, our job here is to integrate workflow and
maintain the same feature set. It shouldn't be about proposing fundamental
plugin design changes.

—
Reply to this email directly or view it on GitHub.

While that is true.. I don't know of a good way to implement this
functionality and it may make sense to do the PR to remove such a feature
first unless we can actually do this change..

One way might be to optionally depend on work flow plug in. I have seen
others do this but I don't know how they did it.

@jacob-keller Right, I didn't see a way of doing it for workflow. So, the easiest thing (for now) might be to mark it as a missing feature for Workflow jobs and not have that point block this PR?

Then, separately have a discussion on the merits/demerits etc of auto-removing triggers. This will either result in a task to remove the feature completely (for all build types), or a task to find a way of making it work for workflow.

I think that is fine myself. I would rather not block trigger support just
because we are missing a relatively minor feature.
On Jul 27, 2015 3:42 AM, "Tom Fennelly" notifications@github.com wrote:

In
src/main/java/com/sonyericsson/hudson/plugins/gerrit/trigger/GerritServer.java
#240 (comment)
:

@@ -914,14 +915,21 @@ private void rename(String newName) {
* @param oldName the old name of the Gerrit server
*/
private void changeSelectedServerInJobs(String oldName) {

for (AbstractProject job : PluginImpl.getConfiguredJobs_(oldName)) {

GerritTrigger trigger = (GerritTrigger)job.getTrigger(GerritTrigger.class);

for (Job job : PluginImpl.getConfiguredJobs_(oldName)) {

// TODO: find a way to handle add/remove of triggers

if (!(job instanceof AbstractProject)) {

return;

@jacob-keller https://github.com/jacob-keller Right, I didn't see a way
of doing it for workflow. So, the easiest thing (for now) might be to mark
it as a missing feature for Workflow jobs and not have that point block
this PR?

Then, separately have a discussion on the merits/demerits etc of
auto-removing triggers. This will either result in a task to remove the
feature completely (for all build types), or a task to find a way of making
it work for workflow.

—
Reply to this email directly or view it on GitHub
https://github.com/jenkinsci/gerrit-trigger-plugin/pull/240/files#r35523862
.

Agreed with @tfennelly’s summary.

jenkinsadmin · 2015-07-11T12:01:25Z

Thank you for a pull request! Please check this document for how the Jenkins project handles pull requests

not sure if they pass though

tfennelly · 2015-07-13T11:02:00Z

Didn't @rsandell suggest also to update the error to include the job name?

@jacob-keller Where's that?

tfennelly · 2015-07-13T11:02:45Z

The tests compile now, but there are failures galore :) Maybe you guys can help me make sense of these?

There's a newer version, but 1.11.1 is the version that git-server 2.3 has a dep on.

Why is this not coming in as a transitive dep of jenkins-core ?

jacob-keller · 2015-07-13T15:45:04Z

@tfennelly, it was suggested that you add the job name as part of the failure message, but you didn't get to that yet.

rsandell · 2015-08-11T13:42:09Z

...a/com/sonyericsson/hudson/plugins/gerrit/trigger/hudsontrigger/data/TriggeredItemEntity.java

            if (project == null) {
-                project = Hudson.getInstance().getItemByFullName(projectId, AbstractProject.class);
+                project = Hudson.getInstance().getItemByFullName(projectId, Job.class);


inherital sin.

rsandell · 2015-08-11T13:55:31Z

🐛 Found mostly just small nits.

tfennelly · 2015-08-11T14:47:41Z

@rsandell I fixed what I reasonably could from your review. I don't think the others should hold up this PR so hopefully you can take back that bug please ;)

tfennelly · 2015-08-11T14:49:11Z

@rsandell and if you can point me to the SomethingApi that you are talking about then we can review that. I went through all changes and fixed backward compatibility wherever it was relevant, so there's nothing outstanding in this PR afaik.

tfennelly · 2015-08-11T14:51:07Z

@rsandell oh and I purposely didn't touch/fix things like the use of Hudson instead of Jenkins. I fixed the ones you pointed to, but in general I do not consider that to be part of what this PR is about.

jglick · 2015-08-11T18:26:51Z

🐝

rsandell · 2015-08-12T19:12:33Z

https://github.com/jenkinsci/gerrit-trigger-plugin/blob/master/src/main/java/com/sonyericsson/hudson/plugins/gerrit/trigger/api/GerritTriggerApi.java

tfennelly · 2015-08-13T07:44:24Z

@rsandell GerritTriggerApi didn't change.

rsandell · 2015-08-14T10:31:33Z

@tfennelly on the use of Hudson instead of Jenkins; This plugin contains too many old/bad practices for any one person to fix them all in a simple pull request. So we use the principle of inhetital sin i.e. if you touch a line you inherit all the sins of that line and gets asked to fix it, because they are now your sins :) That way we can hopefully inch our way to a better code base instead of giving up and never do anything about it.

That does not apply to for example bad architecture that spans over multiple lines and files though. I did not ask you for example to convert the rebuild actions to use a transient factory even though you've touched lines in relation to that ;)

tfennelly · 2015-08-14T10:59:33Z

@rsandell While I'm a person of zero religion/faith or supernatural beliefs of any kind now, I would have been born, baptised and educated within the Roman Catholic religion (as with most Irish people). So, I'm very familiar with sick ideas such as that of Ancestral/Original sin i.e. inheriting someone elses sins.

So while I always thought I had been "cleansed" at baptism, I now find my sole has been tarnished with your bad deeds. Is that how it works? Grrrrrrrr 😸

tfennelly · 2015-08-14T11:01:05Z

@rsandell anyway ... back to the main point ... this PR needs to move forward if we can 😄

rsandell · 2015-08-14T11:12:19Z

...est/java/com/sonyericsson/hudson/plugins/gerrit/trigger/hudsontrigger/GerritTriggerTest.java

@@ -1149,14 +1154,6 @@ public void testGerritEventManualEvent() {
        trigger.createListener().gerritEvent(event);

        verify(listener).onTriggered(same(project), same(event));
-
-        verify(project).scheduleBuild2(


You are no longer verifying that the schedule2 method is actually called, the proxy above will only fail if it gets scheduled with bad parameters, but will pass the test if its not scheduled at all.

rsandell · 2015-08-14T11:23:01Z

Repent and thou shall be merged!

Sorry couldn't help myself 😈

Moving forward: I found some motivation to still not like the schedule thingie. 🐛 for removing the verify of schedule2. But I've gone through the rest and I it looks good.

tfennelly · 2015-08-14T12:03:06Z

@rsandell fair point on the non-verify of the schedule2 call. Will fix that now. Thanks.

tfennelly · 2015-08-14T12:22:40Z

@rsandell ok, that should be ok now (assuming CI tests pass + over-picky checkstyles).

rsandell · 2015-08-14T13:21:30Z

Sorry @tfennelly I was a bit lazy in my last comment.

I'm still not liking the schedule method in the trigger class.
the verification that the job is actually scheduled still has the potential of getting borked with future updates, i.e. changes could be made in the plugin that unknowingly works around the test verification, maybe you could spy on Jenkins.queue.schedule?
and the if here https://github.com/jenkinsci/gerrit-trigger-plugin/blob/master/src/main/resources/com/sonyericsson/hudson/plugins/gerrit/trigger/hudsontrigger/GerritTrigger/config.jelly#L171

tfennelly · 2015-08-14T13:50:41Z

@rsandell added the <if>. Hopefully the tests all still pass coz not sure that instanceof check will work in the jelly.

As for the schedule, there may be a way of doing it differently by spying on the Queue, but I'd really not like to start into another round of dev on this PR for something that's not actually "broken" (i.e. we just dislike the current approach). This PR has now been sitting around for nearly a month (waiting mostly on you 😉). Is there any chance we can move these changes along and revisit the schedule issue to explore other ways of doing it.

The schedule method is protected, but I can also mark it with that @InternalUseOnly annotation (forget the exact name).

rsandell · 2015-08-14T14:58:43Z

But you did break the tests, they don't test the same thing any more.

tfennelly · 2015-08-14T15:23:51Z

@rsandell specifically where are they not testing the same thing? You were saying that it was no longer verifying that the schedule method was bing called. That's fixed now. Where is the difference now?

[JENKINS-26010] Workflow compatibility

rsandell · 2015-08-15T00:31:31Z

I fixed the build failure and cleaned up the tests in 136d511 after the merge.

rsandell · 2015-08-17T09:56:39Z

https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger#GerritTrigger-Version2.15.0beta1%28releasedAug172015%29

tfennelly · 2015-08-17T11:29:22Z

@rsandell thanks for that Bobby. I'll take it for a drive and test it again.

tfennelly · 2015-08-17T11:30:07Z

@reviewbybees done

Workflow compatibility, stage 1

07075f4

rsandell reviewed Jul 10, 2015
View reviewed changes

tfennelly added 2 commits July 10, 2015 16:32

Getting rid of AbstractProject

a56938a

Added TODO on EventListener re possible use of ParameterizedJob

813c290

rsandell reviewed Jul 10, 2015
View reviewed changes

Upgrade rebuild-plugin

6e87548

rsandell reviewed Jul 10, 2015
View reviewed changes

tfennelly added 3 commits July 10, 2015 17:33

Upgrade git-plugin

fb4d4d8

AbstractBuild -> Run in core code (where possible)

53d52e3

Fix error spotted by @rsandell

e67379d

amuniz reviewed Jul 10, 2015
View reviewed changes

Get the tests to compile

024782a

not sure if they pass though

tfennelly added 4 commits July 13, 2015 13:03

Updated git-client plugin dep to v1.11.1

f84c610

There's a newer version, but 1.11.1 is the version that git-server 2.3 has a dep on.

Added commons-io dep (scope=provided)

ddb0822

Why is this not coming in as a transitive dep of jenkins-core ?

Fixed checkstyle error in test class

2031da3

Fix DependencyQueueTaskDispatcherTest

e8fb882

rsandell reviewed Aug 11, 2015
View reviewed changes

Updates based on comments from @rsandell

00d41b6

Checkstyle (yawn)

c3ce41f

rsandell reviewed Aug 14, 2015
View reviewed changes

Fixed missing check for call to schedule2 ala @rsandell review

f55bd54

<j:if test="${it.job instanceof hudson.model.AbstractProject}">

c4f8562

rsandell added a commit that referenced this pull request Aug 15, 2015

Merge pull request #240 from tfennelly/JENKINS-26010

5661bcf

[JENKINS-26010] Workflow compatibility

rsandell merged commit 5661bcf into jenkinsci:master Aug 15, 2015

jglick mentioned this pull request May 24, 2016

[JENKINS-26024] Display a more informative error message jenkinsci/rebuild-plugin#39

Merged

[JENKINS-26010] Workflow compatibility #240

[JENKINS-26010] Workflow compatibility #240

Conversation

tfennelly commented Jul 10, 2015 • edited by TWestling Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rsandell commented Jul 10, 2015

GLundh commented Jul 10, 2015

scoheb commented Jul 10, 2015

jacob-keller commented Jul 10, 2015

tfennelly commented Jul 10, 2015

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

rsandell commented Jul 10, 2015

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

jenkinsadmin commented Jul 11, 2015

tfennelly commented Jul 13, 2015

tfennelly commented Jul 13, 2015

jacob-keller commented Jul 13, 2015

Choose a reason for hiding this comment

rsandell commented Aug 11, 2015

tfennelly commented Aug 11, 2015

tfennelly commented Aug 11, 2015

tfennelly commented Aug 11, 2015

jglick commented Aug 11, 2015

rsandell commented Aug 12, 2015

tfennelly commented Aug 13, 2015

rsandell commented Aug 14, 2015

tfennelly commented Aug 14, 2015

tfennelly commented Aug 14, 2015

Choose a reason for hiding this comment

rsandell commented Aug 14, 2015

tfennelly commented Aug 14, 2015

tfennelly commented Aug 14, 2015

rsandell commented Aug 14, 2015

tfennelly commented Aug 14, 2015

rsandell commented Aug 14, 2015

tfennelly commented Aug 14, 2015

rsandell commented Aug 15, 2015

rsandell commented Aug 17, 2015

tfennelly commented Aug 17, 2015

tfennelly commented Aug 17, 2015

tfennelly commented Jul 10, 2015 •

edited by TWestling

Loading