Skip to content

Conversation

@amuniz
Copy link
Member

@amuniz amuniz commented Jul 3, 2015

https://issues.jenkins-ci.org/browse/JENKINS-27136

Currently Workflow jobs can not be triggered when a GitHub push hook is received, this PR makes it possible.

In this document there is information about the required changes in plugins to make them compatible with Workflow. This changes have been applied here.

@reviewbybees

pom.xml Outdated
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reason?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The minimun Workflow compatible core version is 1.580.1

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

compatible with what?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any Workflow related feature requires core 1.580.X. Since I'm adding Workflow compatibility, the plugin requires 1.580.X now.

See https://github.com/jenkinsci/workflow-plugin/blob/master/README.md#installation

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@KostyaSha

This doesn't mean that you must update core dependencies in non workflow plugins

SCMTriggerItem was added in 1.568. 1.580.x is the next LTS after that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And this is right answer

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@amuniz a tip: if you change this line to

<version>1.580.1</version> <!-- first LTS after SCMTriggerItem -->

then this whole comment thread becomes hidden by default. :-)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jglick 🙀

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

facepalm

@ghost
Copy link

ghost commented Jul 3, 2015

This pull request originates from a CloudBees employee. At CloudBees, we require that all pull requests be reviewed by other CloudBees employees before we seek to have the change accepted. If you want to learn more about our process please see this explanation.

@s0undt3ch
Copy link

I'm realy after this ... 👍

@KostyaSha
Copy link
Member

👎 until #57 will be merged. Also this change looks like breaking interfaces change.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

formating

@amuniz
Copy link
Member Author

amuniz commented Jul 3, 2015

@KostyaSha the only way to make this compatible with Workflow jobs is changing interfaces. Not sure how this impact in #57

@lanwen
Copy link
Member

lanwen commented Jul 3, 2015

please wait for #57 because of hard rebase process instead

@tfennelly
Copy link
Member

@amuniz for the methods that were modified, maybe you could override them instead, deprecating the old method signatures?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you'll need to add a null check on Jenkins.getInstance(). Otherwise, we'll be getting FindBugs errors I think.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

new jenkins has getJenkinsInstance instead

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Starting from 1.596 only AFAIK

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then just copy-paste it realisation and put to static function imho.

@jenkinsadmin
Copy link
Member

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please don't collapse in one line, really difficult read.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will be a CCE if it is not in fact a ParameterizedJob. 🐛

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another place where the 1.621 method would be nicer.

@jglick
Copy link
Member

jglick commented Aug 11, 2015

🐝

@jglick
Copy link
Member

jglick commented Aug 11, 2015

🐝

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems we need the withBridgeMethods magic here as well

@oleg-nenashev
Copy link
Member

@amuniz
Did you agree on the binary compatibility impact with @lanwen and @KostyaSha . There're some issues in the PR, but IIRC there was a formal breakage in the previous release. Probably the compatibility loss is OK now.

@lanwen
Copy link
Member

lanwen commented Aug 11, 2015

i'm ok to merge it. But @KostyaSha thinks that bumping core version before all other useful PRs will be closed on current core version may cause this plugin unusable for older jenkins instances.

(it should be squashed to limited set of commits before merge happens, as of 30 commits for such small change is strange, but please wait until green light)

@jglick
Copy link
Member

jglick commented Aug 11, 2015

If the plugin maintainer desires commit squashing I would suggest that be done as part of the merge rather than destroying history in the PR itself.

@KostyaSha
Copy link
Member

@jglick i can suggest you firstly work with recena and amuniz PRs in CB forks and only after review send to maintainers. Never saw in jenkinsci PRs with so many commits and issues before. Back to upstream repos when their PRs wouldn't have "child" issues.
I'm always squashing my commits and i have no time for doing it instead of your full time employees.

@oleg-nenashev could you say what exactly was broken for you in last releases?

@amuniz
Copy link
Member Author

amuniz commented Aug 12, 2015

@KostyaSha just ask for squash before you are going to merge, I'll do it.

The current amount of revisions and comments in every PR is hopefully going to significantly increase the code base quality in the Jenkins community in general. Moreover, I think is quite good for other developers to have all this review information available publicly, since it is, from my point if view, a nice source of knowledge.

@KostyaSha
Copy link
Member

@amuniz CB pays you for your work, but it doesn't mean that CB that hired and locked all possible jenkins related devs must lock jenkins activities on their internal plans/needs. This noise is waste of time for FOSS devs, instead of working on new features and other plugins i'm getting 100 comments with newbie errors. Compare to @jglick PRs that doesn't require many discussions.

I will back to this PR when we resolve other planned features/fixes and will be ok with core bump.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change makes the Javadoc comment in line 133 obsolete, and without that, AbstractProject is an unused import as well.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@daniel-beck thanks. Fixed.

amuniz added 2 commits August 16, 2015 18:58
Conflicts:
	src/main/java/org/jenkinsci/plugins/github/config/GitHubPluginConfig.java
@amuniz
Copy link
Member Author

amuniz commented Aug 17, 2015

Merge conflicts resolved.

@lanwen
Copy link
Member

lanwen commented Aug 17, 2015

@amuniz please don't rebase. We have 3 or 4 prs in "must have" queue before we are going to merge this pr. I'll do the rebase by myself when the time will come

@amuniz
Copy link
Member Author

amuniz commented Aug 24, 2015

@lanwen ok. If you face some issue while merging, ping me.

@amuniz
Copy link
Member Author

amuniz commented Sep 1, 2015

@lanwen is there any pending PR blocking this to merge yet?

@KostyaSha
Copy link
Member

@amuniz core update blocks it.

@amuniz
Copy link
Member Author

amuniz commented Sep 1, 2015

@KostyaSha could you elaborate please? What's wrong with the core update?

@KostyaSha
Copy link
Member

1.554.1 (2014/04/30)
1.565.3 (2014/10/01)
1.580.1 (2014/10/29)

  1. So soon it will be possible to bump new version
  2. Not all planned features are done, if we will change something after, you will jump with "backward compatibility is broken" so better wait. I don't remember exact plan, but notifyCommit and generic push trigger is one of.

@lanwen
Copy link
Member

lanwen commented Sep 1, 2015

no, think generic trigger is too complex to move workflow in queue.

And while git-plugin of new version is already depends on core version with workflow think we should try to merge this.

@KostyaSha
Copy link
Member

ok, as you wish, i tired from this workflow spam

@lanwen
Copy link
Member

lanwen commented Sep 3, 2015

please review #82

@lanwen
Copy link
Member

lanwen commented Sep 3, 2015

Merged in #82

@lanwen lanwen closed this Sep 3, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.