Jenkinsfile building from PR

[David Brooks]

Hey all,

We currently have a GitHub Organization Folder that is told to build projects that have a Jenkinsfile in their root. However, when I create a branch with a brand new Jenkinsfile on a repo that never had a Jenkinsfile before, the PR is not being built using the Jenkinsfile in the PR. I read https://support.cloudbees.com/hc/en-us/articles/227246367-Why-Jenkinsfile-changes-Are-Not-Reflected-in-PR-Build but don't understand why I was not a trusted source. I am an Admin of our GitHub organization and a team I am apart of was added to this specific repo with Write access.

I don't want to merge in the Jenkinsfile without it first being run and tested. It seems as if this issue was addressed in https://github.com/jenkinsci/github-branch-source-plugin/pull/114 and tag github-branch-source-2.01 however, my Jenkins is running version 2.06 so I don't understand why this is still occurring.

Any ideas are welcomed!

Thanks,

David

[Stephen Connolly]

Jenkins does not have permission to query collaborators 

Any ideas are welcomed!

Thanks,

David

--
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/a329e568-0cb3-47d6-8138-4a6c69cbae82%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Sent from my phone

[Łukasz Zachulski]

I'm curious, is it the same behavior for Bitbucket?

[Stephen Connolly]

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 <lzach...@gmail.com> 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 jenkinsci-de...@googlegroups.com.

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.

[David Brooks]

So the only way for Jenkins to use a Jenkinsfile to build/test a PR is by having that Jenkinsfile already merged into master? How do you test updates to your Jenkinsfile?

[Stephen Connolly]

On Mon 12 Jun 2017 at 13:15, David Brooks <dbr...@intrepid.io> wrote:

So the only way for Jenkins to use a Jenkinsfile to build/test a PR is by having that Jenkinsfile already merged into master? How do you test updates to your Jenkinsfile?

Give Jenkins an api token with repo:admin permissions and then it can see the collaborators 

That's the "today" solution 

Next week should have different answers (may even be this week if I can avoid interruptions)

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/53da2e6e-89f6-4646-8a35-ff18358510ec%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[David Brooks]

Hi Stephen,

Our API token currently has repo, read:org, admin:repo_hook, user:email. What else are we missing? I don't see an explicit option for repo:admin

[Stephen Connolly]

On 12 June 2017 at 15:02, David Brooks <dbr...@intrepid.io> wrote:

Hi Stephen,

Our API token currently has repo, read:org, admin:repo_hook, user:email. What else are we missing? I don't see an explicit option for repo:admin

Yes, this is where it gets crazy. The *user account* that the token was created in needs to have some permissions in the github organization (or the github repo) also.

I haven't played with it sufficiently to say what the exact minimum permission set is. I keep meaning to bash GitHub on the head to get this easier to configure.

 

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/14ad603a-b7bc-4955-bdb3-38aeaee1d0a4%40googlegroups.com.

[Jesse Glick]

On Mon, Jun 12, 2017 at 10:10 AM, Stephen Connolly
<stephen.al...@gmail.com> wrote:
> The *user account* that the token was
> created in needs to have some permissions in the github organization (or the
> github repo) also.
>
> I haven't played with it sufficiently to say what the exact minimum
> permission set is.

https://developer.github.com/v3/repos/collaborators/#review-a-users-permission-level

requires push access on the repository.

[David Brooks]

Doing GET /repos/:owner/:repo/collaborators/:username/permission on the user account the api token was generated from reveals "permission": "admin" which would signify push access :/

[Łukasz Zachulski]

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?

[David Brooks]

I believe we are experiencing the same issue that others are in this PR and are just waiting for it to merge: https://github.com/jenkinsci/github-branch-source-plugin/pull/134

[Stephen Connolly]

I just managed to get my changes for BitBucket in a form where it should be safe for merging:

https://github.com/jenkinsci/bitbucket-branch-source-plugin/pull/53 

I now have to do the same changes for GitHub Branch Source.

If you are trying to make changes to behaviour of either plugin and your changes are not on top of these JENKINS-43507 refactorings, you are going to have a bad time

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/30f61634-d1c0-4a17-9b7a-8a394c1c7cd2%40googlegroups.com.

[Stephen Connolly]

Will be superseded by JENKINS-43507 changes

--

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 jenkinsci-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/73b0b77d-a634-435a-8feb-aacfa145e540%40googlegroups.com.