A Concourse resource for pull requests on Github. Written in Go and based on the Github V4 (GraphQL) API. Inspired by the original, with some important differences:
- Github V4:
check
only requires 1 API call per 100th open pull request. (See #costs for more information). - Fetch/merge:
get
will always merge a specific commit from the Pull request into the latest base. - Metadata:
get
andput
provides information about which commit (SHA) was used from both the PR and base. - Webhooks: Does not implement any caching thanks to GraphQL, which means it works well with webhooks.
Make sure to check out #migrating to learn more.
Parameter | Required | Example | Description |
---|---|---|---|
repository |
Yes | itsdalmo/test-repository |
The repository to target. |
access_token |
Yes | A Github Access Token with repository access (required for setting status on commits). N.B. If you want github-pr-resource to work with a private repository. Set repo:full permissions on the access token you create on GitHub. If it is a public repository, repo:status is enough. |
|
v3_endpoint |
No | https://api.github.com |
Endpoint to use for the V3 Github API (Restful). |
v4_endpoint |
No | https://api.github.com/graphql |
Endpoint to use for the V4 Github API (Graphql). |
paths |
No | terraform/*/*.tf |
Only produce new versions if the PR includes changes to files that match one or more glob pattern. |
ignore_paths |
No | .ci/* |
Inverse of the above. Pattern syntax is documented in filepath.Match. |
disable_ci_skip |
No | true |
Disable ability to skip builds with [ci skip] and [skip ci] in commit message or pull request title. |
skip_ssl_verification |
No | true |
Disable SSL/TLS certificate validation on git and API clients. Use with care! |
Note: If v3_endpoint
is set, v4_endpoint
must also be set (and the other way around).
Produces new versions for all commits (after the last version) ordered by the committed date. A version is represented as follows:
pr
: The pull request number.commit
: The commit SHA.committed
: Timestamp of when the commit was committed. Used to filter subsequent checks.
If several commits are pushed to a given PR at the same time, the last commit will be the new version.
Note on webhooks:
This resource does not implement any caching, so it should work well with webhooks (should be subscribed to push
events).
One thing to keep in mind however, is that pull requests that are opened from a fork and commits to said fork will not
generate notifications over the webhook. So if you have a repository with little traffic and expect pull requests from forks,
you'll need to discover those versions with check_every: 1m
for instance. check
in this resource is not a costly operation,
so normally you should not have to worry about the rate limit.
Parameter | Required | Example | Description |
---|---|---|---|
skip_download |
No | true |
Use with get_params in a put step to do nothing on the implicit get. |
Clones the base (e.g. master
branch) at the latest commit, and merges the pull request at the specified commit
into master. This ensures that we are both testing and setting status on the exact commit that was requested in
input. Because the base of the PR is not locked to a specific commit in versions emitted from check
, a fresh
get
will always use the latest commit in master and report the SHA of said commit in the metadata. Both the
requested version and the metadata emitted by get
are available to your tasks as JSON:
.git/resource/version.json
.git/resource/metadata.json
When specifying skip_download
the pull request volume mounted to subsequent tasks will be empty, which is a problem
when you set e.g. the pending status before running the actual tests. The workaround for this is to use an alias for
the put
(see telia-oss#32 for more details).
put: update-status <-- Use an alias for the pull-request resource
resource: pull-request
params:
path: pull-request
status: pending
get_params: {skip_download: true}
Note that, should you retrigger a build in the hopes of testing the last commit to a PR against a newer version of
the base, Concourse will reuse the volume (i.e. not trigger a new get
) if it still exists, which can produce
unexpected results (#5). As such, re-testing a PR against a newer version of the base is best done by pushing an
empty commit to the PR.
Parameter | Required | Example | Description |
---|---|---|---|
path |
Yes | pull-request |
The name given to the resource in a GET step. |
status |
No | SUCCESS |
Set a status on a commit. One of SUCCESS , PENDING , FAILURE and ERROR . |
context |
No | unit-test |
A context to use for the status. (Prefixed with concourse-ci , defaults to concourse-ci/status ). |
comment |
No | hello world! |
A comment to add to the pull request. |
comment_file |
No | my-output/comment.txt |
Path to file containing a comment to add to the pull request (e.g. output of terraform plan ). |
resource_types:
- name: pull-request
type: docker-image
source:
repository: teliaoss/github-pr-resource
resources:
- name: pull-request
type: pull-request
check_every: 24h
webhook_token: ((webhook-token))
source:
repository: itsdalmo/test-repository
access_token: ((github-access-token))
jobs:
- name: test
plan:
- get: pull-request
trigger: true
version: every
- put: pull-request
params:
path: pull-request
status: pending
- task: unit-test
config:
platform: linux
image_resource:
type: docker-image
source: {repository: alpine/git, tag: "latest"}
inputs:
- name: pull-request
run:
path: /bin/sh
args:
- -xce
- |
cd pull-request
git log --graph --all --color --pretty=format:"%x1b[31m%h%x09%x1b[32m%d%x1b[0m%x20%s" > log.txt
cat log.txt
on_failure:
put: pull-request
params:
path: pull-request
status: failure
- put: pull-request
params:
path: pull-request
status: success
The Github API(s) have a rate limit of 5000 requests per hour (per user). This resource will incur the following costs:
check
: Minimum 1, max 1 per 100th open pull request.in
: Fixed cost of 1. Fetches the pull request at the given commit.out
: Minimum 1, max 3 (1 for each ofstatus
,comment
andcomment_file
).
E.g., typical use for a repository with 125 open pull requests will incur the following costs for every commit:
check
: 2 (paginate 125 PR's with 100 per page)in
: 1 (fetch the pull request at the given commit ref)out
: 1 (set status on the commit)
With a rate limit of 5000 per hour, it could handle 1250 commits between all of the 125 open pull requests in the span of that hour.
If you are coming from jtarchie/github-pullrequest-resource, its important to know that this resource is inspired by but not a drop-in replacement for the original. Here are some important differences:
source
:v4_endpoint
(see description above)
put
:comment
(see description above)
source
:repo
->repository
ci_skip
->disable_ci_skip
(the logic has been inverted and itstrue
by default)api_endpoint
->v3_endpoint
put
:comment
->comment_file
(because we addedcomment
)
src
:uri
: We fetch the URI directly from the Github API instead.private_key
: We clone over HTTPS using the access token for authentication.username
: Same as abovepassword
: Same as aboveonly_mergeable
: We are opinionated and simply fail toget
if it does not merge.
get
:fetch_merge
: We are opinionated and always do a fetch_merge.
src
:base
:disable_forks
require_review_approval
authorship_restriction
label
git_config
get
:git.*
put
:merge.*
label