That's is really interesting.
Recently I've came up with scenario when I wanted to build only selected
PRs and theirs destination branch. Unfortunately it looks like Bitbucket
Branch Source Plugin work other way around, by comparing PR source.
I've found it possible by making a change to Bitbucket Branch Source Plugin
by inverting the condition:
diff --git a/src/main/java/com/cloudbees/jenkins/plugins/bitbucket/
BitbucketSCMSource.java b/src/main/java/com/cloudbees/jenkins/plugins/
bitbucket/BitbucketSCMSource.java
index d3a2298..a78ac9e 100644
--- a/src/main/java/com/cloudbees/jenkins/plugins/bitbucket/
BitbucketSCMSource.java
+++ b/src/main/java/com/cloudbees/jenkins/plugins/bitbucket/
BitbucketSCMSource.java
@@ -386,9 +386,9 @@ public class BitbucketSCMSource extends SCMSource {
new ContributorMetadataAction(pull.getAuthorLogin
(), null, null)
);
observe(criteria, observer, listener,
- pull.getSource().getRepository().getOwnerName(),
- pull.getSource().getRepository().getRepositoryName
(),
- pull.getSource().getBranch().getName(),
+ pull.getDestination().getRepository().getOwnerName
(),
+ pull.getDestination().getRepository().
getRepositoryName(),
+ pull.getDestination().getBranch().getName(),
hash,
head);
if (!observer.isObserving()) {
@Stephen Do you see that a viable case worth making it an optional
parameter? Or should I general keep to the default policy?
W dniu niedziela, 11 czerwca 2017 09:01:18 UTC+2 użytkownik Stephen
Connolly napisał:
>
> Bitbucket is CRAZY....
>
> I am currently trying to get my UI refactoring for GitHub and Bitbucket
> branch sources pushed and cut a beta release.
>
> Bitbucket cloud has the "fun" issue that forks of private repositories
> *by default* are not visible to the owner of the forked repository. This
> means forking is less useful on Bitbucket.org... but you can fork into
> another repo in the team account. The branch source should therefore look
> for forks in the origin repo and the team account (as they are safe to
> assume as collaborators)... it will do this for private repositories only
> at present.
>
> Bitbucket server at least reifies the refs of pull requests into the
> target repository. This means you can see the changes always, but that
> exposes the trust issue.
>
> With all these, the concern is somebody using a pull request as a vector
> to do bold stuff... it's really a bigger concern with public repositories.
>
> It is a worry for any job type and any CI server. Somebody can add a unit
> test that starts bitcoin mining. With pipeline, you can put timeouts on
> different build steps and put some steps in sandboxes such as docker. This
> provides a way to prevent the unit tests from being a viable vector. It
> also makes config as code a target, so what we do is use the pipeline from
> the destination branch for PRs from non-trusted users.
>
> GitHub has added new apis that let you determine collaborators, but we are
> waiting my UI refactoring to merge as this makes the api change easier to
> introduce without regression in behaviour (some may want the existing
> behaviour: underspecified as it is) so we need the UI refactoring to make
> it easier to configure.
>
> The previous api would only list collaborators if Jenkins has a token with
> repo:admin. If it doesn't have those permissions it will not see the list
> of collaborators... if it does, it will see a sublist of collaborators that
> it is able to see (yeah crazy)
>
> Bitbucket doesn't have an api to give collaborator info, so currently we
> do not discover pull requests of public repositories at all on Bitbucket.
> (Seemingly only 4% of repos ion Bitbucket.org are forked outside of their
> account) In reality we should be fine discovering origin PRs as well as
> "sibling forks" (forking to a different repo in same account) for public
> repositories... but I need to find a way to surface this in the UI without
> leaving a "enable legacy mode" option (this problem is currently blocking
> the release of the beta)
>
> This coming week should see the betas released (once I have confidence
> that upgrading will not cause major regressions)
>
> The UI refactoring has enabled writing lots of tests that were previously
> impossible to write, as well as enabling more feature parity and code reuse
> between plugins, but it is taking longer than I originally estimated due to
> some of the complexity discovered on the way.
>
> On Sat 10 Jun 2017 at 15:21, Łukasz Zachulski <[email protected]
> <javascript:>> wrote:
>
>> I'm curious, is it the same behavior for Bitbucket?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected] <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/a15e0710-3e08-4c6b-ac86-5b34d96fdb10%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> Sent from my phone
>
--
You received this message because you are subscribed to the Google Groups
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/30f61634-d1c0-4a17-9b7a-8a394c1c7cd2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
