I've gotten this feature request a lot.

This is something the CI system should support, not the resource. It's job is only to return new versions, not frankenstein those version numbers.

Please comment on the issue for concourse support.

Thanks

The problem

We are using this pull request resource to create Bosh releases in our Concourse pipeline, for a deployment of Cloud Foundry. Bosh releases (and potentially other repositories) can contain scripts which are executed when the release is compiled in the pipeline. Executing scripts from a pull request combined with use of an AWS instance profile (for Concourse) presents a massive security problem. Anybody could raise a pull request with malicious code which grabs the instance profile's metadata (AWS keys).

Proposed solution

Add some optional resource parameters which limit the source of the pull request. We still want people to be able to raise pull requests, but only the right people will cause a new version in Concourse to trigger. Two ideas could be:

• limit to pull requests from the same repo (forks are not allowed to submit)
• limit to GitHub users/groups

We are going to fork this repository and work on a solution. Meanwhile, we would be grateful for any advice you may have on the matter. We would like to be able to merge our solution upstream and close our fork once we are done.

Could you please add git lfs support? All you need to do is add to the dockerfile this command:

RUN set -x
&& curl -s https://packagecloud.io/install/repositories/github/git-lfs/script.deb.sh | bash
&& apt-get install -y git-lfs
&& git lfs install

I am having an issue posting status on_success/on_failure. All my repos are setup the same, but only one of them succeeds and the other error with trace below. I suspect it is something with repo configuration but I am at a loss. Any ideas?

resources:

#succeeds

• name: pr-simple-service
  type: pull-request
  source:
  access_token: {{github-access-token}}
  private_key: {{github-private-key}}
  repo: scpprd/simple-service
  uri: [email protected]:scpprd/simple-service.git

#fails

• name: pr-svc-transaction-adapter
  type: pull-request
  source:
  repo: scpprd/svc-transaction-adapter
  uri: [email protected]:scpprd/svc-transaction-adapter.git
  access_token: {{github-access-token}}
  private_key: {{github-private-key}}

Error

Identity added: /tmp/git-resource-private-key (/tmp/git-resource-private-key)
/usr/lib/ruby/gems/2.3.0/gems/octokit-4.6.2/lib/octokit/response/raise_error.rb:16:in `on_complete': POST https://api.github.com/repos/scpprd/MembershipHistory/statuses/6c1f77b0deee06ea87c278c8316040e29b5c2946: 404 - Not Found // See: https://developer.github.com/v3 (Octokit::NotFound)
	from /usr/lib/ruby/gems/2.3.0/gems/faraday-0.10.0/lib/faraday/response.rb:9:in `block in call'
	from /usr/lib/ruby/gems/2.3.0/gems/faraday-0.10.0/lib/faraday/response.rb:61:in `on_complete'
	from /usr/lib/ruby/gems/2.3.0/gems/faraday-0.10.0/lib/faraday/response.rb:8:in `call'
	from /usr/lib/ruby/gems/2.3.0/gems/octokit-4.6.2/lib/octokit/middleware/follow_redirects.rb:73:in `perform_with_redirection'
	from /usr/lib/ruby/gems/2.3.0/gems/octokit-4.6.2/lib/octokit/middleware/follow_redirects.rb:61:in `call'
	from /usr/lib/ruby/gems/2.3.0/gems/faraday-0.10.0/lib/faraday/rack_builder.rb:139:in `build_response'
	from /usr/lib/ruby/gems/2.3.0/gems/faraday-0.10.0/lib/faraday/connection.rb:377:in `run_request'
	from /usr/lib/ruby/gems/2.3.0/gems/faraday-0.10.0/lib/faraday/connection.rb:177:in `post'
	from /usr/lib/ruby/gems/2.3.0/gems/sawyer-0.8.1/lib/sawyer/agent.rb:94:in `call'
	from /usr/lib/ruby/gems/2.3.0/gems/octokit-4.6.2/lib/octokit/connection.rb:154:in `request'
	from /usr/lib/ruby/gems/2.3.0/gems/octokit-4.6.2/lib/octokit/connection.rb:28:in `post'
	from /usr/lib/ruby/gems/2.3.0/gems/octokit-4.6.2/lib/octokit/client/statuses.rb:43:in `create_status'
	from /usr/lib/ruby/gems/2.3.0/gems/octokit-4.6.2/lib/octokit.rb:46:in `method_missing'
	from /opt/resource/lib/status.rb:13:in `create!'
	from /opt/resource/lib/commands/out.rb:52:in `output'
	from /opt/resource/lib/commands/out.rb:82:in `<main>'

Concourse out is always followed from in, that makes having several contexts updated expensive. If the resource allows for status update this price can be reduced at least to pending status updates that could be combined.

Hi,

I believe I noticed a bug in the resource, but it might be me misinterpreting something.

Let's say that a developer creates PR and almost instantaneously adds a new change to the branch ... and the pipeline is set to run more than one pr validations at a time. I did not investigate so thoroughly but it feels that now the two executions compete which one to update the status leaving the results a random mixup between the two checks.

Long story short, is there a check when the update status is triggered is it from the right (latest) version of the PR?

If not - it seems running PRs one by one is the only workaround I can think of.

We have public repositories that we'd like to build only after a repository contributor reviews the PR. We'd like to keep the approval workflow within GitHub, as opposed to using trigger: false in Concourse and forcing the reviewer to navigate to Concourse and start the build.

The requested feature would add a comment_trigger property to the source configuration. If a comment from a repository contributor exactly matches the value of comment_trigger, the resource will recognize the PR as an input.

If this, or something like this, fits with the project vision, I'm happy to implement.

Will it work with for example:

• bitbucket
• gitlab
• something-else

I would like to be able to do something like this:

BASE=git config pullrequest.basebranch
CHANGED_FILES=git --no-pager diff --name-only $(git merge-base HEAD $BASE)

This will give me a list of all files changed with this PR. Unfortunately in order this to works it needs the base branch to be fetched too. Instead, the second fetched branch is always the master. I am not sure is fetching it is by mistake or fetching master instead of the base branch is the mistake.

In any case could you please change the fetch to obtain the base branch instead (or additionally) to the master?

I'm trying to use this extension.

Here is mine pipeline:

resources:
- name: resource-transinet-concourse
  type: pull-request
  source:
    repo: amenzhinsky/transinet-concourse
    access_token: <token>

But I get this error:

/usr/lib/ruby/gems/2.2.0/gems/octokit-4.3.0/lib/octokit/response/raise_error.rb:16:in `on_complete': GET https://api.github.com/repos/amenzhinsky/transinet-concourse/pulls/: 404 - Not Found // See: https://developer.github.com/v3 (Octokit::NotFound)

I't s like the problem caused by the trailing slash because https://api.github.com/repos/amenzhinsky/transinet-concourse/pulls works file

I want to update the status of a PR right away when detected, but my job takes a long time to run. As a result, I am stacking a "detection" job in front of my long-running job so that I can see on the PR that Concourse is about to run the job:

resource_types:
- name: pull-request
  type: docker-image
  source:
    repository: jtarchie/pr

resources:
  - name: git-pr
    type: pull-request
    source:
      access_token: {{github-token}}
      repo: emcniece/concourse-pr-test

jobs:
- name: detect-pr
  plan:
  - get: git-pr
    trigger: true
    version: every
  - put: git-pr
    params:
      path: git-pr
      status: pending

- name: docker
  plan:
  - get: git-pr
    passed: [detect-pr]
    trigger: true
  - task: tag
    config:
      image_resource:
        type: docker-image
        source:
          repository: alpine
      platform: linux
      outputs:
        - name: tag
      run:
        path: sh
        args: ["-c", "echo test > tag/name"]
  - put: git-pr
    params:
      path: git-pr
      status: success

This looks like:

So the first job sets a "pending" status on the PR, then after the docker job is done the PR is set to "success". The docker job could also use the on_failure and on_success conditions to set the PR status as well and I am doing this in other pipelines.

Is this the best way to add a "pending" status to a PR? Is there some sort of on_start condition for jobs, or is there a better pattern for setting pending status while a job executes?

Hi, will this work for bitbucket repos or only github, If not would it be a simple task to fork and modify

we are using docker compose to startup concourse build with pullrequest-resource .

but it always failed on git-pull-requests for checking .

stderr:
/usr/lib/ruby/gems/2.3.0/gems/httpclient-2.8.3/lib/httpclient/session.rb:625:in `rescue in create_socket': getaddrinfo: Try again (api.github.com:443) (SocketError)
	from /usr/lib/ruby/gems/2.3.0/gems/httpclient-2.8.3/lib/httpclient/session.rb:607:in `create_socket'
	from /usr/lib/ruby/gems/2.3.0/gems/httpclient-2.8.3/lib/httpclient/ssl_socket.rb:21:in `create_socket'
	from /usr/lib/ruby/gems/2.3.0/gems/httpclient-2.8.3/lib/httpclient/session.rb:752:in `block in connect'
	from /usr/lib/ruby/2.3.0/timeout.rb:91:in `block in timeout'
	from /usr/lib/ruby/2.3.0/timeout.rb:101:in `timeout'
	from /usr/lib/ruby/gems/2.3.0/gems/httpclient-2.8.3/lib/httpclient/session.rb:748:in `connect'
	from /usr/lib/ruby/gems/2.3.0/gems/httpclient-2.8.3/lib/httpclient/session.rb:511:in `query'
	from /usr/lib/ruby/gems/2.3.0/gems/httpclient-2.8.3/lib/httpclient/session.rb:177:in `query'
	from /usr/lib/ruby/gems/2.3.0/gems/httpclient-2.8.3/lib/httpclient.rb:1242:in `do_get_block'
	from /usr/lib/ruby/gems/2.3.0/gems/httpclient-2.8.3/lib/httpclient.rb:1019:in `block in do_request'
	from /usr/lib/ruby/gems/2.3.0/gems/httpclient-2.8.3/lib/httpclient.rb:1133:in `protect_keep_alive_disconnected'
	from /usr/lib/ruby/gems/2.3.0/gems/httpclient-2.8.3/lib/httpclient.rb:1014:in `do_request'
	from /usr/lib/ruby/gems/2.3.0/gems/httpclient-2.8.3/lib/httpclient.rb:856:in `request'
	from /usr/lib/ruby/gems/2.3.0/gems/faraday-0.11.0/lib/faraday/adapter/httpclient.rb:38:in `call'
	from /usr/lib/ruby/gems/2.3.0/gems/faraday-0.11.0/lib/faraday/response.rb:8:in `call'
	from /usr/lib/ruby/gems/2.3.0/gems/faraday-0.11.0/lib/faraday/response.rb:8:in `call'
	from /usr/lib/ruby/gems/2.3.0/gems/octokit-4.6.2/lib/octokit/middleware/follow_redirects.rb:73:in `perform_with_redirection'
	from /usr/lib/ruby/gems/2.3.0/gems/octokit-4.6.2/lib/octokit/middleware/follow_redirects.rb:61:in `call'
	from /usr/lib/ruby/gems/2.3.0/gems/faraday-0.11.0/lib/faraday/rack_builder.rb:139:in `build_response'
	from /usr/lib/ruby/gems/2.3.0/gems/faraday-0.11.0/lib/faraday/connection.rb:377:in `run_request'
	from /usr/lib/ruby/gems/2.3.0/gems/faraday-0.11.0/lib/faraday/connection.rb:140:in `get'
	from /usr/lib/ruby/gems/2.3.0/gems/sawyer-0.8.1/lib/sawyer/agent.rb:94:in `call'
	from /usr/lib/ruby/gems/2.3.0/gems/octokit-4.6.2/lib/octokit/connection.rb:154:in `request'
	from /usr/lib/ruby/gems/2.3.0/gems/octokit-4.6.2/lib/octokit/connection.rb:84:in `paginate'
	from /usr/lib/ruby/gems/2.3.0/gems/octokit-4.6.2/lib/octokit/client/pull_requests.rb:20:in `pull_requests'
	from /usr/lib/ruby/gems/2.3.0/gems/octokit-4.6.2/lib/octokit.rb:46:in `method_missing'
	from /opt/resource/lib/filters/all.rb:11:in `pull_requests'
	from /opt/resource/lib/repository.rb:17:in `block in pull_requests'
	from /opt/resource/lib/repository.rb:16:in `each'
	from /opt/resource/lib/repository.rb:16:in `reduce'
	from /opt/resource/lib/repository.rb:16:in `pull_requests'
	from /opt/resource/lib/commands/check.rb:10:in `output'
	from /opt/resource/lib/commands/check.rb:23:in `<main>'

There has been a feature request to be able to rerun PRs.

If a PR get's a new HEAD it will rerun. Is that good enough?

I'd like to refrain from creating a bot that watches for comments on PRs. Perhaps there is another part of state on the PR that is easily configurable, which could be use for versioning. Title?

Hello,

Thanks for this wonderful resource for concourse. I've been having a lot of fun with it in my local play environment.

Today I started to use this in my enterprise. Our enterprise GH is signed by an internal CA so the cert is not known. I have set skip_ssl_verification but am still seeing this error message.

resource script '/opt/resource/check []' failed: exit status 1
 
stderr:
/usr/lib/ruby/gems/2.3.0/gems/httpclient-2.8.3/lib/httpclient/ssl_socket.rb:103:in `connect': SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed (Faraday::SSLError)
         from /usr/lib/ruby/gems/2.3.0/gems/httpclient-2.8.3/lib/httpclient/ssl_socket.rb:103:in `ssl_connect'
         from /usr/lib/ruby/gems/2.3.0/gems/httpclient-2.8.3/lib/httpclient/ssl_socket.rb:41:in `initialize'
         from /usr/lib/ruby/gems/2.3.0/gems/httpclient-2.8.3/lib/httpclient/ssl_socket.rb:26:in `new'
         from /usr/lib/ruby/gems/2.3.0/gems/httpclient-2.8.3/lib/httpclient/ssl_socket.rb:26:in `create_socket'
         from /usr/lib/ruby/gems/2.3.0/gems/httpclient-2.8.3/lib/httpclient/session.rb:752:in `block in connect'
         from /usr/lib/ruby/2.3.0/timeout.rb:91:in `block in timeout'
         from /usr/lib/ruby/2.3.0/timeout.rb:101:in `timeout'
         from /usr/lib/ruby/gems/2.3.0/gems/httpclient-2.8.3/lib/httpclient/session.rb:748:in `connect'
         from /usr/lib/ruby/gems/2.3.0/gems/httpclient-2.8.3/lib/httpclient/session.rb:511:in `query'
         from /usr/lib/ruby/gems/2.3.0/gems/httpclient-2.8.3/lib/httpclient/session.rb:177:in `query'
         from /usr/lib/ruby/gems/2.3.0/gems/httpclient-2.8.3/lib/httpclient.rb:1242:in `do_get_block'
         from /usr/lib/ruby/gems/2.3.0/gems/httpclient-2.8.3/lib/httpclient.rb:1019:in `block in do_request'
         from /usr/lib/ruby/gems/2.3.0/gems/httpclient-2.8.3/lib/httpclient.rb:1133:in `protect_keep_alive_disconnected'
         from /usr/lib/ruby/gems/2.3.0/gems/httpclient-2.8.3/lib/httpclient.rb:1014:in `do_request'
         from /usr/lib/ruby/gems/2.3.0/gems/httpclient-2.8.3/lib/httpclient.rb:856:in `request'
         from /usr/lib/ruby/gems/2.3.0/gems/faraday-0.11.0/lib/faraday/adapter/httpclient.rb:38:in `call'
         from /usr/lib/ruby/gems/2.3.0/gems/faraday-0.11.0/lib/faraday/response.rb:8:in `call'
         from /usr/lib/ruby/gems/2.3.0/gems/faraday-0.11.0/lib/faraday/response.rb:8:in `call'
         from /usr/lib/ruby/gems/2.3.0/gems/octokit-4.6.2/lib/octokit/middleware/follow_redirects.rb:73:in `perform_with_redirection'
         from /usr/lib/ruby/gems/2.3.0/gems/octokit-4.6.2/lib/octokit/middleware/follow_redirects.rb:61:in `call'
         from /usr/lib/ruby/gems/2.3.0/gems/faraday-0.11.0/lib/faraday/rack_builder.rb:139:in `build_response'
         from /usr/lib/ruby/gems/2.3.0/gems/faraday-0.11.0/lib/faraday/connection.rb:377:in `run_request'
         from /usr/lib/ruby/gems/2.3.0/gems/faraday-0.11.0/lib/faraday/connection.rb:140:in `get'
         from /usr/lib/ruby/gems/2.3.0/gems/sawyer-0.8.1/lib/sawyer/agent.rb:94:in `call'
         from /usr/lib/ruby/gems/2.3.0/gems/octokit-4.6.2/lib/octokit/connection.rb:154:in `request'
         from /usr/lib/ruby/gems/2.3.0/gems/octokit-4.6.2/lib/octokit/connection.rb:84:in `paginate'
         from /usr/lib/ruby/gems/2.3.0/gems/octokit-4.6.2/lib/octokit/client/pull_requests.rb:20:in `pull_requests'
         from /usr/lib/ruby/gems/2.3.0/gems/octokit-4.6.2/lib/octokit.rb:46:in `method_missing'
         from /opt/resource/lib/filters/all.rb:11:in `pull_requests'
         from /opt/resource/lib/repository.rb:17:in `block in pull_requests'
         from /opt/resource/lib/repository.rb:16:in `each'
         from /opt/resource/lib/repository.rb:16:in `reduce'
         from /opt/resource/lib/repository.rb:16:in `pull_requests'
         from /opt/resource/lib/commands/check.rb:10:in `output'
         from /opt/resource/lib/commands/check.rb:23:in `<main>'

Any idea what I can do to resolve? I will most likely create a docker image with our certs in it for a workaround.

git-resource has paths and ignore-paths parameters which we heavily rely on in our monorepo style projects to test/build/publish only the apps that have had src code changes. Is this something that could also be supported by pullrequest-resource?

Hey JT,

Totally looking at using this for a project and wanted to check out the example URL but I couldn't load the page ;/

Okay, this is tricky, and I'm not quite sure how to do in concourse. When a pull request is opened, I'd actually like to do a separate build for each individual commit in the pr, with the "put" going back to the commit. I suspect the only way to handle this is to do it manually inside a task, since concourse doesn't really seem to have the concept of resources-of-resources, but I was hoping you'd have another idea.

Hi, is it possible to add a option in check to support check returning new pr only if there's no pr in pending status?
I supposed this option might be useful because some pipeline jobs share resources and can take only one build at the same time.

Would be nice to use webhooks instead of polling to trigger PR jobs.

It'd be nice to be able to trigger when a given label is set on the PR.

to me, at any rate.
The example doesn't help my confusion since there it is the same name as the resource.

https://developer.github.com/v4/

This might help simplify filters, as well as improve certain configurations of the resource which result in multiple REST requests made to Github.

Could you please evaluate the context parameter like here: https://github.com/cloudfoundry-community/slack-notification-resource/blob/c1686fb4b6ed41a4a28d6de497889e5fae7e2cfd/out#L99

This will help D.R.Y. up job definitions where there are several build contexts and statuses used.

hello! i'm looking for some input about current support or feasibility for a feature.

problem statement

• no clickable link in GitHub status to bring user to associated concourse job run

discussion

GitHub maps the target_url from the status POST to Details button

expected

something similar to this:

actual

Is there a way to get the URL in there? Thanks!

Does the uri allow you to override the github url with an enterprise url?

For instance, I have the following config:

- name: my-project
    type: pull-request
    source:
      access_token: {{access_token}}
      private_key: {{github-private-key}}
      uri: https://github.mycompany.com/org/repo.git
      branch: develop
      username: {{USERNAME}}
      password: {{PASSWORD}}
      repo: org/repo
      git_config:
      - name: http.sslVerify
        value: false
    ```
However, when I do this I get this error message:

https://api.github.com/repos/org/repo/pulls?direction=desc&per_page=100&sort=updated&state=open: 401 - Bad credentials

So you can see it is not using my github enterprise url...

I see that the Docker image for this resource type is pulled each time it is used. This is great, I do want the resource-type to be latest version, but is it necessary to re-pull the image even when it is present in the system and the checksums match?

I suspect that this is a Concourse issue, not a resource-type issue...

Hey,
Thank you for this repo. It works perfect with public repo as for private I have some issues. Take the following config

  - name: automation-pr
    type: pull-request
    source:
      repo: ahelal/mypriverepo
      private_key: {{github_private_key}}
      access_token: {{github_token}}

The check works and i get a Ref, but In the get part fails with the following error

Cloning into '/tmp/build/get'...
fatal: could not read Username for 'https://github.com': No such device or address
/opt/resource/lib/in.rb:25:in `<main>': git clone failed (RuntimeError)

not sure what am I doing wrong ?

Latest(Mar 1, 2017) failed to pull submodules, 'v20' works well. repo is 'greenplum-db/gpdb', logs are attached below.

Identity added: /tmp/git-resource-private-key (/tmp/git-resource-private-key)
Cloning into '/tmp/build/get'...
Checking out files: 100% (24205/24205), done.
Switched to branch 'pr-coverity_fix'
Submodule 'gpAux/client' ([email protected]:greenplum-db/gpclients.git) registered for path 'gpAux/client'
Submodule 'gpAux/extensions/googletest' ([email protected]:google/googletest.git) registered for path 'gpAux/extensions/googletest'
Submodule 'gpAux/extensions/pgbouncer/source' ([email protected]:greenplum-db/pgbouncer.git) registered for path 'gpAux/extensions/pgbouncer/source'
Submodule 'gpAux/extensions/plr/source' ([email protected]:greenplum-db/plr.git) registered for path 'gpAux/extensions/plr/source'
Submodule 'gpAux/extensions/postgis-2.0.3/source' ([email protected]:greenplum-db/postgis.git) registered for path 'gpAux/extensions/postgis-2.0.3/source'
Submodule 'gpMgmt/bin/pythonSrc/ext' ([email protected]:greenplum-db/pythonsrc-ext.git) registered for path 'gpMgmt/bin/pythonSrc/ext'
Submodule 'src/bin/gpfdist/ext' ([email protected]:greenplum-db/gpfdist-ext.git) registered for path 'src/bin/gpfdist/ext'
Cloning into '/tmp/build/get/gpAux/client'...
Cloning into '/tmp/build/get/gpAux/extensions/googletest'...
Cloning into '/tmp/build/get/gpAux/extensions/pgbouncer/source'...
Cloning into '/tmp/build/get/gpAux/extensions/plr/source'...
Cloning into '/tmp/build/get/gpAux/extensions/postgis-2.0.3/source'...
Cloning into '/tmp/build/get/gpMgmt/bin/pythonSrc/ext'...
Cloning into '/tmp/build/get/src/bin/gpfdist/ext'...
Submodule path 'gpAux/client': checked out '355026e7858fdb5fa505ab02a3d62121dca40937'
Fetched in submodule path 'gpAux/extensions/googletest', but it did not contain ec44c6c1675c25b9827aacd08c02433cccde7780. Direct fetching of that commit failed.

If fetch_merge is false, the status of the pull request is set correctly to pending, but if fetch_merge is true it will not be set correctly.

Below is an example of a pipeline.

resource_types:
- name: pull-request
  type: docker-image
  source:
    repository: jtarchie/pr

resources:
- name: pull-request
  type: pull-request
  source:
    repo: kei-yamazaki/concourse-sandbox
    access_token: {{github-access-token}}
    uri: '[email protected]:kei-yamazaki/concourse-sandbox.git'
    private_key: {{github-private-key}}

jobs:
- name: concourse-sandbox-job
  plan:
  - get: pull-request
    trigger: true
    # When fetch_merge is enabled, status does not become pending
    # params: {fetch_merge: true}
  - put: pull-request
    params: {path: pull-request, status: pending}
  - task: some-task
    config:
      platform: linux
      image_resource:
        type: docker-image
        source: {repository: ubuntu}
      run:
        path: bash
        args:
        - -cx
        - sleep 15
        - ls -al
    ensure:
      put: pull-request
      params: {path: pull-request, status: success}

It will be nice if the resource has an option to automatically merge the PR.

Note it will be nice to have a way to specify the merge_method. It should also make sure that the review process is completed as well.

The way I am picturing using this feature is with creating an additional job that depends on the other(s) that does put with merge - in a case of merge operation failing - the validation job(s) will not be wrongfully red just because of that.

Hi there,

I am seeing this issue with the concourse/lite vagrant image:

Job Config:

resource_types:
- name: pull-request
  type: docker-image
  source:
    repository: jtarchie/pr

resources:
- name: repo
  type: pull-request
  source:
    repo: gregorskii/concourse-test
    uri: [email protected]:gregorskii/concourse-test.git
    access_token: TOKEN
    private_key: |
      -----BEGIN RSA PRIVATE KEY-----
     KEY DATA
      -----END RSA PRIVATE KEY-----

jobs:
- name: test pull request
  plan:
  - get: repo
    trigger: true
  - put: repo
    params:
      path: repo
      status: pending
  - task: do something with git
    config:
      platform: linux
      image: docker:///concourse/git-resource
      run:
        path: sh
        args:
        - -c
        - cd repo && git --no-pager show
      inputs:
      - name: repo
        path: ""
    on_success:
      put: repo
      params:
        path: repo
        status: success
    on_failure:
      put: repo
      params:
        path: repo
        status: failure

What do you think?

As per the docs:

status: Required. The status of success, failure, error, or pending.`

But I want to make a comment without changing the status of a PR. I have some parallel jobs and I want them to post comments asynchronously without affecting the success/fail state of the job doing the testing. Is this possible?

I have a private repo configured below with an access token that has "repo" permissions. Check succeeds but an in fails with below error.

- name: pr-simple-service
  type: pull-request
  source:
    access_token: {{github-access-token}}
    private_key: {{github-private-key}}
    repo: scpprd/simple-service

Error

Identity added: /tmp/git-resource-private-key (/tmp/git-resource-private-key)
Cloning into '/tmp/build/get'...
fatal: could not read Username for 'https://github.com': No such device or address
/opt/resource/lib/in.rb:34:in `<main>': git clone failed (RuntimeError)

Any ideas?

fix this!

I have a working configuration - thank you so much for this project. Is there a way to reduce the delay between PR submission and detection?

Also, how is PR status checked? Does it poll the Github API, or does it subscribe to a webhook?

I'm having trouble understanding how to access the metadata associated with the detected PR. As per the README:

There is git config information set on the repo about the PR, which can be consumed within your tasks.

I would like to get the branch of the detected PR and use this as an environment variable in another task. For example:

resources:
- name: git-pr
  type: pull-request
  check_every: 15s
  source:
    access_token: {{github-token}}
    repo: {{app-build-repo}}
    uri: {{app-build-uri}}

jobs:
- name: test-things
  plan:
  - get: git-pr
    trigger: true
    version: every
  - get: my-docker-image
  - task: test
    image: my-docker-image
    params:
      GIT_BRANCH: git-pr.branch
    config:
      platform: linux
      run:
        dir: /
        path: sh
        args:
          - -exc
          - |
            echo $GIT_BRANCH
            cd /app
            npm test
    on_success:
      put: git-pr
      params:
        path: git-pr
        status: success
    on_failure:
      put: git-pr
      params:
        path: git-pr
        status: failure

This results in the test task echoing git-pr.branch, which is me misunderstanding how this works. Ideally, the echo $GIT_BRANCH line would actually be something like git checkout $GIT_BRANCH, the echo just lets me see if it is populating the GIT_BRANCH variable.

I see that from #58 we can't get the URL. Is it possible to use this other data (branch, id, etc) as variables for other tasks? How is this achieved?

I'd like to migrate the resource to only support the new feature with concourse v1.2 version: every. This allows the resource to iterated over without having to check the github status for state.

I'd like to give a migration path, though.

I'm thinking of making the feature an opt in feature for now via source so the check step return all versions.

If the source value was not provided a deprecation notice will be displayed, which will warn about the impending change.

Is it possible to expose the PR metadata to be used as env vars within other resources? Eg, Slack notifications which link to the github pull request after success/failure? Similar to how $ATC_EXTERNAL_URL is exposed.

Here's the scenario; (Auto merge is disabled so PR merges are manual) There are 3 open PRs and all of them have successfully built and reported back to git successfully. Once we merge one of the PRs into the main branch, the main CI build is successfully triggered, which also triggers the tests. Also after the tests are done, the newest PR opened is also triggered. I'm assuming it is building the most recent PR for the branch we're merging into, but we would like to also build other branches that are open for the base branch that we just merged into.

The reason is because once the branch is changed, we would like to rerun those PRs with the new changes in the case that we may find some issues before merging in the PR.

Is it possible to add an option to skip the clone after the status update? This operation contributes nothing and depending on the setup could be expensive.

for some PRs which have conflict with base branch, the merge-pull-requests will fail, which is correct.
However, after manually closed the conflicted PRs, the merge-pull-requests still uses local PR, and seems not sync the status of PRs from server again.
So the merge-pull-requests stays "RED" while the PR is closed in fact, which doesn't need a merge any more.

Hi, when set every: true in source, the PRs returned by check should be ordered from latest to oldest. Because when set version: every at get, it starts from the version after the most recently used and move forward. In current order(oldest to latest), new PRs can never be iterated to.

a pull request could have the following status on github side,

1. open
2. closed
3. approved

How can I get those approved pull request?
I think these should be in the implementation, but I just fail to find an example. Please kindly help me out, thanks ~

Currently if you get a fetch merged pull request and do a put back to the pull request it has the new commit sha of the merge as the new version. This is causing the build to trigger twice when you have version: every on the get.

- get: pull-request-src
   trigger: true
   params:
     version: every
     fetch_merge: true

- put: pull-request-src
   params:
     path: pull-request-src
     status: pending
     context: assemble

See build 81 with the original commit sha and putting to the commit sha of the merge. Which caused build 82 to start with the commit sha of the merge.

It would be helpful to have an optional configuration to specify that the resource should fetch what the result of the merge would be rather than the origin branch. This would add some feature parity with Travis-CI. Travis-CI: How-Pull-Requests-are-Tested

The option could be something like fetch_merge: bool. It should default to false so that the behavior doesn't change for existing users. In the event that a PR is unmergeable and fetch_merge is true an error should be given.

The line in question, which is affected by custom contextes

The pullrequest-resource in outputs the following error, but doesn't fail completely:

fatal: Refusing to fetch into current branch refs/heads/master of non-bare repository
Already on 'master'
Your branch is up-to-date with 'origin/master'.

This results in strange behaviour where the pullrequest-resource has cloned the git repository, but not fetched the changes from the pull request. The subsequent steps in the build plan continue to execute without including the pull request changes.

Steps to reproduce:

1. Create a pipeline with using pullrequest-resource pointing to a repository let's call it usera/repo
2. Fork the repo into another user account userb/repo
3. Make some trivial change to the master of userb/repo (it's important the change is made in master) and create a pull request from userb/repo:master to usera/repo:master
4. Check the pipeline in for the pullrequest-resource

Expected outcome:
The in of pullrequest-resource should fetch the changes from the pull request we should see the changes from userb/repo:master in Concourse.

Actual outcome:
The in of pullrequest-resource fails to fetch the changes from the pull request. It also doesn't fail in an obvious way it outputs the error but then exits with success. We see only the contents of usera/repo:master in Concourse.

This only happens when the pull request is made from the master branch of the fork. The asset/lib/in.rb seems to assume the pull request is made from a branch other than master branch_ref = pr['head']['ref'] what happens in this case is branch_ref = 'master' and then system("git fetch -q origin pull/#{id}/head:#{branch_ref} 1>&2") results in the Already on 'master' error. Quick workaround hack is to hardcode branch_ref = 'tmp', but that has other implications so not a full solution.