Pipeline support #69

proski · 2019-03-28T17:43:59Z

This comment is here to reflect the current state of the PR, it is updated after every push

This is a rebased commit by @rhencke to support pipelines. It has been successfully tested both with pipelines and with traditional projects (Free Style, Matrix and Maven).

Most changes are already in the master branch. The remaining part is a commit to enable pipeline support in global configuration. That is necessary to make users understand that the support is incomplete and there are other ways to access Bitbucket Server from a pipeline. Also, a section about pipeline has been added to README.md.

rhencke · 2019-03-28T23:00:23Z

Thanks for taking this up (I am the original author of ea4a885). If there's any questions I can help answer feel free to ping me here or email me directly.

proski · 2019-03-29T00:27:53Z

Thanks for taking this up (I am the original author of ea4a885). If there's any questions I can help answer feel free to ping me here or email me directly.

Thank you, I've updated the description. Sorry for misattributing the original work!

I went through the code line-by-line, it's actually a very clean implementation. I made it even less intrusive by requiring Job to implement ParameterizedJob and Queue.Task. That way, I can cast it without fallbacks.

I also made changes to reduce interdependencies between classes. That way, I could split the commit into smaller parts.

The customized messages cannot even be configured in the pipeline, so I don't consider it a defect in this PR. Rather, we should find a way to post arbitrary messages to Stash from the pipeline, which would be a large separate task.

proski · 2019-03-29T18:34:16Z

I have fixed a major bug I introduced while applying to original patch manually (enabled projects were treated as disabled and vice versa). I've done some testing, everything appears to be working correctly. Now it's time for others to test.

proski · 2019-03-29T20:43:43Z

Changes to variable names and comments only.

rhencke · 2019-03-30T11:14:25Z

@proski Thank you - I appreciate the kind words. :)
Looking over everything this looks good. I noticed you've been making other improvements to the plugin as well in other PRs. We use this plug-in pretty heavily where I work, and there are actually quite a few things that could be done to improve the speed and functionality of this plugin while keeping with its spirit, but I've been holding off on working on it because there really hasn't been an active maintainer. If you I think that it would be worth it I'd be happy to file some issues and implement PR's to improve things as well.

One of the ideas is to revamp the way that this plug-in tracks build status - it currently traverses the comment chain to determine when things need to build and this ends up not being very efficient at scale - this could be switched to use the native build status API in Bitbucket Server. That would reduce the size of this codebase, make it much faster on more active repos, and also take advantage of build status API which currently requires adding the stash notifier plugin if you want to use it.

Another is adding native support for Bitbucket Server webhooks - this would eliminate polling completely and also instantly start builds when pull requests triggered them instead of having to heavily poll the server via the comments API.

If you think this would be something you be open to let me know, and I can dig in as well. :)

rhencke · 2019-03-30T11:24:41Z

(also also, if you like, Git maintains author and committer separately in commits, though they are normally the same - this is the use case it helps track. When you are rebasing you can do a git commit --amend --author='Robert Hencke <[email protected]>' and it should then show the author as me and the committer as you)

proski · 2019-03-30T17:46:18Z

@rhencke, I've set your authorship on the commits that are derived from your patch.

It's good to know that your patch is heavily used. My changes are mostly to avoid any fallbacks. For instance, I was uncomfortable about passing null to CredentialsMatchers.firstOrNull. Those fallbacks are not needed for traditional projects and pipelines, but I don't wan't to cause a security issue to some other kind of projects.

PRs are getting approved slowly here, so I don't feel good about asking you to do more changes that may wait for a long time.

I believe traversing the comments is unavoidable with the current design, as the plugin is looking for "test this please" and "NO test". We can tell the plugin to stop looking for PRs with the successful build status, but then "test this please" would stop working for the projects that have been tested successfully. It's not a typical case ("test this please" is more commonly used in case of build failure), but it can be confusing to the users.

Speaking of the build status, do you set it from the pipeline? Stash Notifier is a post-build publisher, it cannot be configured from the pipeline GUI. Are you doing it from the pipeline code? If we add Stash Notifier functionality to this plugin, we could configure it from the GUI.

I believe Bitbucket plugin supports webhooks, so it may be better just to migrate to it. But the last commit in the code was on December 6, 2017. https://github.com/jenkinsci/bitbucket-plugin

There is also Bitbucket pull request builder. It is being actively developed. It only claims to support Bitbucket.org in README, but I see a reference to Bitbucket server in the code.

rhencke · 2019-03-31T16:20:16Z

Hey @proski :)

It's good to know that your patch is heavily used. My changes are mostly to avoid any fallbacks. For instance, I was uncomfortable about passing null to CredentialsMatchers.firstOrNull. Those fallbacks are not needed for traditional projects and pipelines, but I don't wan't to cause a security issue to some other kind of projects.

That's fair - that sounds like a good idea. I'll be the first to admit the Jenkins API is not my strong suit, so please feel free to improve as you see fit. :)

PRs are getting approved slowly here, so I don't feel good about asking you to do more changes that may wait for a long time.

That's okay! The fact they're getting approved and merged at all is enough for me. :)

I believe traversing the comments is unavoidable with the current design, as the plugin is looking for "test this please" and "NO test". We can tell the plugin to stop looking for PRs with the successful build status, but then "test this please" would stop working for the projects that have been tested successfully. It's not a typical case ("test this please" is more commonly used in case of build failure), but it can be confusing to the users.

I agree, this is true for polling style, unfortunately. But, if web hook support was implemented (would be happy to work on this), then for those who enabled it, Bitbucket Server will just POST the comments to Jenkins as they happened, and all the build would have to do is look at each comment as it arrived. (basically, it'd be a model akin to /git/notifyCommit from the Git plugin, but specific to receiving events for Bitbucket).

Speaking of the build status, do you set it from the pipeline? Stash Notifier is a post-build publisher, it cannot be configured from the pipeline GUI. Are you doing it from the pipeline code? If we add Stash Notifier functionality to this plugin, we could configure it from the GUI.

Yes - exactly. I don't have the code in front of me. It's not pretty, but it's something to the effect of (pseudocode):

StashNotifier.notify('INPROGRESS')
def error
try {
    /* build */
} catch(err) {
	error = err
	throw err
} finally {
	if (error) {
		try {
			StashNotifier.notify('FAILED', error)
		catch (err) {
			error.addSuppressed(err)
		}
	} else {
		StashNotifier.notify('SUCCESS')
	}
}

...which I would love to delete and just configure from the pipeline GUI instead. :)

I believe Bitbucket plugin supports webhooks, so it may be better just to migrate to it. But the last commit in the code was on December 6, 2017. jenkinsci/bitbucket-plugin

Unfortunately, yes. I can't speak for others, but at least in my environment we end up having to install several plugins together (this one, Stash notifier, etc) to stitch together a solution. But it's honestly been a while since I went and looked at what else was available, and tried the latest versions of everything - maybe there's better options now for where some of this work could be focused, or maybe there's something out there that'd be a good swap-out replacement.

There is also Bitbucket pull request builder. It is being actively developed. It only claims to support Bitbucket.org in README, but I see a reference to Bitbucket server in the code.

I'll check that out - thank you! :)

proski · 2019-04-01T19:06:25Z

@rhencke, thank you for your detailed reply. There are some recipes in the StashNotifier README

Scripting is a mixed bag. It's a barrier for entry, but it gives a lot of power if it's needed. Scripting works with multiple components just fine, but GUI doesn't work well if there are multiple components with their own configurations. Either there should be one plugin dealing with Stash-Jenkins interactions, or there should be scriptable low-level plugins and a high-level GUI capable plugin that depends on them.

I also plan to test every plugin with "Bitbucket" in its name as long as it's maintained or at least has an active community.

Back to this PR, my only unresolved concern so far is whether the environment variables are provided to all jobs in the pipeline. I want to have a way to identify the top level project for every Run. That's not your code, the environment variables were handled as parameters until recently.

MyroslavSeliverstov · 2019-04-04T12:26:46Z

Thank you for this PR. It's really valued option for this plugin
I build artifact from your repo from pipeline-support branch. And deploy plugin in my Jenkins.

Looks like I faced two issues.
I had two PR in bitbucket.
I expect that job will be triggered two times. And each build will have just one badge about PR.
Issues:

Job runed just one time. Build marked with two badges (two PRs). In Bitbucket both PRs receive comment about this build, but just one has comment that build - success.
Job run two times. But first build has two badges as well. Comments in PR time to time like it's described above, and sometimes as expected (comment that - build success).

Jenkins ver. 2.138.1

Thanks in advance.

proski · 2019-04-08T21:13:52Z

@MyroslavSeliverstov, I'm sorry, I don't understand either issue. Even the GUI in the screenshots looks unfamiliar to me, except the Stash comments.

I don't think those issues can be fixed in this PR. This PR allows Stash Pull Request Builder to operate on pipelines by using less specific interfaces. There are no other changes here. In particulate, there are no changes to how comments are posted.

There is one change that could actually fix the disappearing job. That's the change from isDisabled to isBuildable. With the current master branch, a job can be disabled but not buildable. In that case, the build would never complete, and the comment about the build result would never get posted. This PR should fix such possibility.

Let's get back to those issues once this PR gets merged. Jenkins logs should help figure out what is happening.

proski · 2019-04-09T21:07:19Z

I've added commits from PRs #67, #72 and #73 to provide full pipeline support. This PR is marked WIP anyway, we can always merge other PRs and rebase this one to exclude already merged changes.

I have found a document how to write a pipeline-compatible plugin: https://jenkins.io/doc/developer/plugin-development/pipeline-integration/

I plan to go through it carefully, it looks like some issues still need to be addressed, e.g. changing BuildListener to TaskListener.

jakub-bochenski · 2019-04-10T11:58:44Z

I've added commits from PRs #67, #72 and #73 to provide full pipeline support.

Just FTR, and as mentioned in #72 I do like the approach of having several self-contained PRs

proski · 2019-04-10T15:26:56Z

I've added commits from PRs #67, #72 and #73 to provide full pipeline support.

Just FTR, and as mentioned in #72 I do like the approach of having several self-contained PRs

I've removed the commits that come from other PRs.

For the purpose of testing, I have a branch in my fork that integrates all those PRs and some other work (mostly warning fixes): https://github.com/proski/stash-pullrequest-builder-plugin/tree/merge-all

I'm open to splitting this PR even further (e.g. taking my environment commit elsewhere) if it helps with merging.

jakub-bochenski · 2019-04-11T11:46:39Z

I also plan to test every plugin with "Bitbucket" in its name as long as it's maintained or at least has an active community.

I've spent some time trying to get https://wiki.jenkins.io/display/JENKINS/Bitbucket+Branch+Source+Plugin to work. I'm still seeing some issues, probably because we are stuck using a 4.x version of Stash/BB

You can configure it with a dsl-like the one seen below. The code is not pretty with all the configuration blocks, but more importantly:

it handles both regular branch builds and PRs (bugged, but still)
it sends notifications (could be improved)
it's configured centrally, no need to repeat the same trigger config in each Jenkinsfile
if I'm not mistaken you can also add other common traits at this level like timestamps (?)

I appreciate all the work done here, and I'm sad to be making a fuss here.
Yet I think before proceeding with this we need to figure out why and if it makes sense to duplicate the functionality already present in another plugin.

It seems to me that the branch source/organization approach is "the way to go" with Pipelines. This is only a gut feeling though. I would be happy to see arguments that show otherwise, or use cases that are not supposed to be/can't be handled by the branch source approach.

Even if this plugin is not going to support pipelines I think it's still going to be useful for many years to come. I don't expect the old-style jobs to disappear any time soon.

    organizations {
        bitbucket {
            repoOwner('acme')
            credentialsId('secret')
            serverUrl('https://stash.acme.com/')
            traits {
                sourceRegexFilter {
                    regex('.*')
                }
                headWildcardFilter {
                    includes("*")
                    excludes("stuff")
                }
            }
        }
    }

    // discover Branches (workaround due to JENKINS-46202)
    configure { node ->
        // node represents <jenkins.branch.OrganizationFolder>
        final traits = node / 'navigators' / 'com.cloudbees.jenkins.plugins.bitbucket.BitbucketSCMNavigator' / 'traits'
        traits << 'com.cloudbees.jenkins.plugins.bitbucket.BranchDiscoveryTrait' {
            strategyId(1) // Exclude branches that are also filed as PRs
        }
        traits << 'com.cloudbees.jenkins.plugins.bitbucket.ForkPullRequestDiscoveryTrait' {
            strategyId(1)
            trust(class: 'com.cloudbees.jenkins.plugins.bitbucket.ForkPullRequestDiscoveryTrait$TrustEveryone')
        }
        traits << 'com.cloudbees.jenkins.plugins.bitbucket.OriginPullRequestDiscoveryTrait' {
            strategyId(1)
        }
        traits << 'com.cloudbees.jenkins.plugins.bitbucket.SSHCheckoutTrait' {
            credentialsId('key')
        }
    }

d8v1dee · 2019-04-11T23:29:57Z

In previous version, a Pull Request triggered with the build phrase would rebuild if there was a commit to the branch trying to be merged to master. In this pull request version, the branch has new commits but isn't building unless the build phrase is entered again

proski · 2019-04-12T06:32:10Z

@d8v1dee, @MyroslavSeliverstov, I see several issues with Jenkins 2.172.

Exception on startup for every project using Stash PR trigger, pipeline or not:

SEVERE: Can't start trigger
java.lang.NullPointerException
	at hudson.model.queue.Tasks.getDefaultAuthenticationOf(Tasks.java:87)
	at stashpullrequestbuilder.stashpullrequestbuilder.StashBuildTrigger.getCredentials(StashBuildTrigger.java:148)
	at stashpullrequestbuilder.stashpullrequestbuilder.StashBuildTrigger.getUsername(StashBuildTrigger.java:154)
	at stashpullrequestbuilder.stashpullrequestbuilder.StashRepository.<init>(StashRepository.java:65)
	at stashpullrequestbuilder.stashpullrequestbuilder.StashPullRequestsBuilder.<init>(StashPullRequestsBuilder.java:24)
	at stashpullrequestbuilder.stashpullrequestbuilder.StashBuildTrigger.start(StashBuildTrigger.java:206)
	at stashpullrequestbuilder.stashpullrequestbuilder.StashBuildTrigger.start(StashBuildTrigger.java:52)
	at hudson.model.AbstractProject.onLoad(AbstractProject.java:313)
	at hudson.model.Project.onLoad(Project.java:97)
	at hudson.model.Items.load(Items.java:373)
	at jenkins.model.Jenkins$14.run(Jenkins.java:3166)
	at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:169)
	at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:296)
	at jenkins.model.Jenkins$5.runTask(Jenkins.java:1096)
	at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:214)
	at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

Probably related, logged periodically for every project with Stash PR Trigger:

Apr 12, 2019 6:08:00 AM stashpullrequestbuilder.stashpullrequestbuilder.StashBuildTrigger run
INFO: Not ready to run.

Only for pipelines, a crash when removing the old comment:

Apr 12, 2019 5:56:03 AM hudson.model.listeners.RunListener report
WARNING: RunListener failed
java.lang.NullPointerException
	at stashpullrequestbuilder.stashpullrequestbuilder.StashRepository.deletePullRequestComment(StashRepository.java:183)
	at stashpullrequestbuilder.stashpullrequestbuilder.StashBuilds.onCompleted(StashBuilds.java:55)
	at stashpullrequestbuilder.stashpullrequestbuilder.StashBuildListener.onCompleted(StashBuildListener.java:36)
	at hudson.model.listeners.RunListener.fireCompleted(RunListener.java:209)
	at org.jenkinsci.plugins.workflow.job.WorkflowRun.finish(WorkflowRun.java:586)
	at org.jenkinsci.plugins.workflow.job.WorkflowRun.access$900(WorkflowRun.java:133)
	at org.jenkinsci.plugins.workflow.job.WorkflowRun$GraphL.onNewHead(WorkflowRun.java:998)
	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.notifyListeners(CpsFlowExecution.java:1452)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$3.run(CpsThreadGroup.java:435)
	at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$1.run(CpsVmExecutorService.java:35)
	at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:131)
	at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
	at jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:59)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

My priority is to fix support for non-pipeline projects. I think I have an idea how to fix the pipeline specific issue, but it has to wait. I pushed a fix, then I realized that there is a bigger issue, so I removed that fix for now.

proski · 2019-04-12T06:45:02Z

@jakub-bochenski, I appreciate your post about Bitbucket Branch Source plugin. I still need to try it with my own hands before I can discuss it in details.

However, I see that supporting pipelines in this plugin can provide a stepping stone from old-style projects to the pipelines. I see a lot of interest, I see many testers here. And the code additions are minimal, most changes are replacing one class with another.

I'll try to extract all the good stuff from this PR in case we don't merge it (such as isBuildable()). It would minimize this PR even further.

But first I need to fix the recent breakage. Either Jenkins released a broken version, or we should stop using the obsolete getDefaultAuthenticationOf, or it's something else in this plugin, or a combination.

jakub-bochenski · 2019-04-12T09:21:12Z

However, I see that supporting pipelines in this plugin can provide a stepping stone from old-style projects to the pipelines. I see a lot of interest, I see many testers here. And the code additions are minimal, most changes are replacing one class with another.

I'm reluctant to include duplicate functionality here, however if there is much call for it I won't block it.
If we do merge it, I would like to have a clear statement of scope and purpose of supporting pipeline, to avoid feature creep etc.

proski · 2019-04-12T20:37:45Z

My fix for NullPointerException in deletePullRequestComment was totally wrong and broke everything including freestyle jobs. I removed it from this branch.

The master branch is OK. Even with this branch as of now, all jobs except the pipelines are working. I'm looking for a fix for deletePullRequestComment, I'll post here once I have something.

proski · 2019-04-13T01:53:27Z

I have added the fix. Here's what was happening.

Jenkins runs StashBuildTrigger#start(), it creates a StashPullRequestsBuilder object and indirectly a StashRepository object.
Jenkins runs StashBuildTrigger#run(), it creates a StashApiClient object and associates it with the StashRepository object.
The BuildStarted comment is posted using the StashApiClient object
The build runs.
Jenkins runs StashBuildTrigger#start() again, it replaces the StashPullRequestsBuilder object and the StashRepository object. There is no link between the new StashRepository and the old StashApiClient object.
The BuildStarted comment is attempted to be removed using the StashApiClient object, which is no longer accessible.

The fix makes StashBuildTrigger#start() hold onto the original StashPullRequestsBuilder object as long as the job argument doesn't change from the current value.

Likewise, StashBuildTrigger#stop() keeps the original StashPullRequestsBuilder object, as I saw stop() being called erratically. The is nothing left in stop(), so it has been removed.

While I don't consider the fix particularly elegant, I believe that Jenkins is behaving unreasonably, and the entry points for the trigger should protect the internal state of the trigger.

Eventually we could restructure the code to be closer to the Jenkins concepts (e.g. an object associated with the job, an object associated with the run), then we could take a less defensive stance. StashPullRequestsBuilder is a good candidate to be removed, it's way too thin and suffers from class envy, as all non-trivial functionality is implemented through StashRepository.

proski · 2019-04-13T19:36:57Z

Pushed a much simpler and nicer fix for the failure to replace the BuildStarted comment. That's what I attempted initially, but one little piece was missing. That piece has also been submitted as #79.

src/main/java/stashpullrequestbuilder/stashpullrequestbuilder/StashBuildTrigger.java

Chocrates · 2019-04-18T20:10:33Z

Looks like with this PR pipeline defined parameters will overwrite plugin supplied variables.
For instance, in our Pipelines we would set our jobs to have "pullRequestId" as a parameter, so that we could run the builds manually if needed. After applying this PR (and bumping jenkins versions) the pipeline defined parameter (empty in this case) overwrites the plugin supplied variable.

dawidmalina · 2019-05-23T21:54:50Z

@proski when we can expect this PR to be merged?

proski · 2019-05-24T00:17:06Z

@proski when we can expect this PR to be merged?

I have no idea. I think we are getting close. Many parts of the original PR are already in the master branch, including one little piece that was merged today.

The remaining parts are getting more straightforward an easy to review. I'm going to remove the commit that deals with the environment variables, as it's not strictly necessary for the minimal pipeline support. It will be resubmitted separately.

On the other hand, we have a security issue (#85) and a fix for a server-killing bug (#93) in review, so changes are they might be merged before this PR.

proski · 2019-06-03T05:58:09Z

Added unit tests.

proski · 2019-06-04T07:10:39Z

Rebased on top of the master branch. Added an extra commit that prevents unit tests from breaking.

rhencke

(I'm listed as author, but I think you get the credit for commit
58416e6 :) Much as it would have been a good idea for me to add better testing...)

proski · 2019-06-04T17:13:26Z

(I'm listed as author, but I think you get the credit for commit
58416e6 :) Much as it would have been a good idea for me to add better testing...)

Thanks. I used my script stg-split to split out whatever I had to change to make the unit tests pass, so the author data got cloned. Will fix it shortly.

proski · 2019-06-08T00:37:17Z

Significant improvement in the startJob implementation. The code uses the "convenience" variant of ParameterizedJobMixIn.scheduleBuild2 that takes care of the quiet time, doesn't require any raw types and returns Queue.Item that can be checked for parameters.

I hope this PR is applied soon. We can always perfection the code in separate PRs. But before this PR is applied, all further work on the pipeline support is essentially blocked. We are turning away potential contributors, because their PRs are not going anywhere.

proski · 2019-06-10T07:22:27Z

Fixed an issue with the global enable checkbox not being populated from the settings (it was always showing as unchecked after loading the system configuration page). It turns out the getter getEnablePipelineSupport was needed to populate the GUI. I had it in the final commit initially, then I removed it because it was unused in the code. It turns out it was used. Reflection is like magic, wonderful when it works, frustrating when it doesn't.

proski · 2019-06-12T06:37:01Z

Improvements in the last commit (global option to enable plugin support):

Configure the descriptor using req.bindJSON without using individual keys
More realistic unit tests
Support for mocking final classes is not needed anymore, not enabling that option

HB-2012 · 2019-06-19T12:14:33Z

Thank you for taking the time to implement pipeline support. I recently updated this plugin on our company Jenkins installation and noticed that pipeline support was completely disabled. We've reverted to the older version and are since waiting for the merge and release of this PR.

If there is anything I can do to help speed up the process, please let me know.

proski · 2019-06-19T21:17:58Z

Thank you for taking the time to implement pipeline support. I recently updated this plugin on our company Jenkins installation and noticed that pipeline support was completely disabled. We've reverted to the older version and are since waiting for the merge and release of this PR.

If there is anything I can do to help speed up the process, please let me know.

@HB-2012: thank you for reporting the issue! The pipeline support was disabled because the code is not ready to support it. It's better not to show the trigger in GUI if it won't work.

Why did you need to revert to an older version? Did it resolve any issue for you? What were the versions?

atzoum · 2019-06-28T13:12:33Z

How far is this PR from being merged? Any possibility to be included in the next version?

jakub-bochenski · 2019-06-28T14:11:28Z

1 of the commits have already been merged, 2 others have been approved by me and are waiting for review by @jimklimov

HB-2012 · 2019-07-01T07:17:39Z

@HB-2012: thank you for reporting the issue! The pipeline support was disabled because the code is not ready to support it. It's better not to show the trigger in GUI if it won't work.

Why did you need to revert to an older version? Did it resolve any issue for you? What were the versions?

The reason we had to revert is because we were on an older version that didn't have the check. Some teams are using this plugin with additional (Power)shell scripts to make it all function somewhat decently. We run quite a lot of plugins and workflows so I'm unsure of the specific use cases, I just know that our users wanted to downgrade after this plugin no longer worked inside a pipeline.

Looking forward to the release! :)

proski · 2019-07-01T09:10:19Z

The reason we had to revert is because we were on an older version that didn't have the check. Some teams are using this plugin with additional (Power)shell scripts to make it all function somewhat decently. We run quite a lot of plugins and workflows so I'm unsure of the specific use cases, I just know that our users wanted to downgrade after this plugin no longer worked inside a pipeline.

@HB-2012: Thank you for the reply. It's actually good that pipeline support was the only reason to revert to an older version. It means that merging this PR would likely fix your setup.

I don't understand how it's possible to use a plugin without pipeline support with pipelines. The only explanation I have is that the Jenkins Pipeline code has a compatibility mode for plugins that only support freestyle projects. Perhaps that mode was activated with the scripts you mentioned.

proski · 2019-07-06T01:35:32Z

This PR is down to one commit now. Getting really close!

proski · 2019-07-08T04:09:49Z

Added a commit to rename the descriptor class, also submitted separately as #116.

README.md

Add a global option to enable pipeline support. If it's enabled, don't require the job to inherit from AbstractProject. Allow any Job subclass that implements ParameterizedJob, which is true both for freestyle projects and for pipelines. Make it clear in the option help text and in README.md that pipeline support is currently experimental. Add workflow-job as a test dependency. Add unit tests to make sure that WorkflowJob is supported only when pipeline support is enabled.

proski mentioned this pull request Mar 28, 2019

Add support for Jenkins Pipeline. #21

Closed

jakub-bochenski added the WIP work in progress label Mar 28, 2019

proski mentioned this pull request Mar 30, 2019

Add support for Jenkins Pipeline. nemccarthy/stash-pullrequest-builder-plugin#110

Merged

This was referenced Apr 8, 2019

Custom @Symbol for StashBuildTrigger #73

Open

UnsupportedOperationException when using Snippet Generator #72

Closed

jakub-bochenski reviewed Apr 15, 2019

View reviewed changes

src/main/java/stashpullrequestbuilder/stashpullrequestbuilder/StashBuildTrigger.java Outdated Show resolved Hide resolved

proski mentioned this pull request Apr 18, 2019

StashBuildTrigger: Only allow jobs derived from AbstractProject #70

Merged

proski mentioned this pull request May 24, 2019

StashBuildEnvironmentContributor: Pass environment variables to pipelines #96

Merged

rhencke reviewed Jun 4, 2019

View reviewed changes

This was referenced Jun 12, 2019

StashRepository: Merge init() into the constructor #105

Merged

StashRepository: Implement in terms of Job, not AbstractProject #106

Merged

proski mentioned this pull request Jun 26, 2019

Replace AbstractProject and AbstractBuild with Job and Run #107

Merged

proski mentioned this pull request Jul 8, 2019

StashBuildTrigger: Rename StashBuildTriggerDescriptor to DescriptorImpl #116

Merged

proski mentioned this pull request Jul 11, 2019

Make some settings optional in pipelines #119

Merged

jakub-bochenski reviewed Jul 11, 2019

View reviewed changes

README.md Show resolved Hide resolved

jakub-bochenski approved these changes Jul 21, 2019

View reviewed changes

jakub-bochenski removed the WIP work in progress label Jul 21, 2019

jakub-bochenski reviewed Jul 21, 2019

View reviewed changes

README.md Show resolved Hide resolved

jakub-bochenski merged commit f5c1fda into jenkinsci:master Jul 22, 2019

proski deleted the pipeline-support branch July 22, 2019 16:55

Uh oh!

Pipeline support #69

Pipeline support #69

Uh oh!

Conversation

proski commented Mar 28, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rhencke commented Mar 28, 2019

Uh oh!

proski commented Mar 29, 2019

Uh oh!

proski commented Mar 29, 2019

Uh oh!

proski commented Mar 29, 2019

Uh oh!

rhencke commented Mar 30, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rhencke commented Mar 30, 2019

Uh oh!

proski commented Mar 30, 2019

Uh oh!

rhencke commented Mar 31, 2019

Uh oh!

proski commented Apr 1, 2019

Uh oh!

MyroslavSeliverstov commented Apr 4, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

proski commented Apr 8, 2019

Uh oh!

proski commented Apr 9, 2019

Uh oh!

jakub-bochenski commented Apr 10, 2019

Uh oh!

proski commented Apr 10, 2019

Uh oh!

jakub-bochenski commented Apr 11, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

d8v1dee commented Apr 11, 2019

Uh oh!

proski commented Apr 12, 2019

Uh oh!

proski commented Apr 12, 2019

Uh oh!

jakub-bochenski commented Apr 12, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

proski commented Apr 12, 2019

Uh oh!

proski commented Apr 13, 2019

Uh oh!

proski commented Apr 13, 2019

Uh oh!

Uh oh!

Chocrates commented Apr 18, 2019

Uh oh!

dawidmalina commented May 23, 2019

Uh oh!

proski commented May 24, 2019

Uh oh!

proski commented Jun 3, 2019

Uh oh!

proski commented Jun 4, 2019

Uh oh!

rhencke left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

proski commented Jun 4, 2019

Uh oh!

proski commented Jun 8, 2019

Uh oh!

proski commented Jun 10, 2019

Uh oh!

proski commented Jun 12, 2019

Uh oh!

HB-2012 commented Jun 19, 2019

proski commented Mar 28, 2019 •

edited

Loading

rhencke commented Mar 30, 2019 •

edited

Loading

MyroslavSeliverstov commented Apr 4, 2019 •

edited

Loading

jakub-bochenski commented Apr 11, 2019 •

edited

Loading

jakub-bochenski commented Apr 12, 2019 •

edited

Loading

rhencke left a comment •

edited

Loading