Pull Request Generator

The Pull Request generator uses the API of an SCMaaS provider (GitHub, Gitea, or Bitbucket Server) to automatically discover open pull requests within a repository. This fits well with the style of building a test environment when you create a pull request.

  1. apiVersion: argoproj.io/v1alpha1
  2. kind: ApplicationSet
  3. metadata:
  4.   name: myapps
  5. spec:
  6.   generators:
  7.   - pullRequest:
  8.       # When using a Pull Request generator, the ApplicationSet controller polls every `requeueAfterSeconds` interval (defaulting to every 30 minutes) to detect changes.
  9.       requeueAfterSeconds: 1800
  10.       # See below for provider specific options.
  11.       github:
  12.         # ...

Note

Know the security implications of PR generators in ApplicationSets. Only admins may create ApplicationSets to avoid leaking Secrets, and only admins may create PRs if the project field of an ApplicationSet with a PR generator is templated, to avoid granting management of out-of-bounds resources.

GitHub

Specify the repository from which to fetch the GitHub Pull requests.

  1. apiVersion: argoproj.io/v1alpha1
  2. kind: ApplicationSet
  3. metadata:
  4.   name: myapps
  5. spec:
  6.   generators:
  7.   - pullRequest:
  8.       github:
  9.         # The GitHub organization or user.
  10.         owner: myorg
  11.         # The Github repository
  12.         repo: myrepository
  13.         # For GitHub Enterprise (optional)
  14.         api: https://git.example.com/
  15.         # Reference to a Secret containing an access token. (optional)
  16.         tokenRef:
  17.           secretName: github-token
  18.           key: token
  19.         # (optional) use a GitHub App to access the API instead of a PAT.
  20.         appSecretName: github-app-repo-creds
  21.         # Labels is used to filter the PRs that you want to target. (optional)
  22.         labels:
  23.         - preview
  24.       requeueAfterSeconds: 1800
  25.   template:
  26.   # ...
  • owner: Required name of the GitHub organization or user.
  • repo: Required name of the GitHub repository.
  • api: If using GitHub Enterprise, the URL to access it. (Optional)
  • tokenRef: A Secret name and key containing the GitHub access token to use for requests. If not specified, will make anonymous requests which have a lower rate limit and can only see public repositories. (Optional)
  • labels: Filter the PRs to those containing all of the labels listed. (Optional)
  • appSecretName: A Secret name containing a GitHub App secret in repo-creds format.

GitLab

Specify the project from which to fetch the GitLab merge requests.

  1. apiVersion: argoproj.io/v1alpha1
  2. kind: ApplicationSet
  3. metadata:
  4.   name: myapps
  5. spec:
  6.   generators:
  7.   - pullRequest:
  8.       gitlab:
  9.         # The GitLab project.
  10.         project: myproject
  11.         # For self-hosted GitLab (optional)
  12.         api: https://git.example.com/
  13.         # Reference to a Secret containing an access token. (optional)
  14.         tokenRef:
  15.           secretName: gitlab-token
  16.           key: token
  17.         # Labels is used to filter the MRs that you want to target. (optional)
  18.         labels:
  19.         - preview
  20.         # MR state is used to filter MRs only with a certain state. (optional)
  21.         pullRequestState: opened
  22.       requeueAfterSeconds: 1800
  23.   template:
  24.   # ...
  • project: Required name of the GitLab project.
  • api: If using self-hosted GitLab, the URL to access it. (Optional)
  • tokenRef: A Secret name and key containing the GitLab access token to use for requests. If not specified, will make anonymous requests which have a lower rate limit and can only see public repositories. (Optional)
  • labels: Labels is used to filter the MRs that you want to target. (Optional)
  • pullRequestState: PullRequestState is an additional MRs filter to get only those with a certain state. Default: “” (all states)

Gitea

Specify the repository from which to fetch the Gitea Pull requests.

  1. apiVersion: argoproj.io/v1alpha1
  2. kind: ApplicationSet
  3. metadata:
  4.   name: myapps
  5. spec:
  6.   generators:
  7.   - pullRequest:
  8.       gitea:
  9.         # The Gitea organization or user.
  10.         owner: myorg
  11.         # The Gitea repository
  12.         repo: myrepository
  13.         # The Gitea url to use
  14.         api: https://gitea.mydomain.com/
  15.         # Reference to a Secret containing an access token. (optional)
  16.         tokenRef:
  17.           secretName: gitea-token
  18.           key: token
  19.         # many gitea deployments use TLS, but many are self-hosted and self-signed certificates
  20.         insecure: true
  21.       requeueAfterSeconds: 1800
  22.   template:
  23.   # ...
  • owner: Required name of the Gitea organization or user.
  • repo: Required name of the Gitea repository.
  • api: The url of the Gitea instance.
  • tokenRef: A Secret name and key containing the Gitea access token to use for requests. If not specified, will make anonymous requests which have a lower rate limit and can only see public repositories. (Optional)
  • insecure: Allow for self-signed certificates, primarily for testing.

Bitbucket Server

Fetch pull requests from a repo hosted on a Bitbucket Server (not the same as Bitbucket Cloud).

  1. apiVersion: argoproj.io/v1alpha1
  2. kind: ApplicationSet
  3. metadata:
  4.   name: myapps
  5. spec:
  6.   generators:
  7.   - pullRequest:
  8.       bitbucketServer:
  9.         project: myproject
  10.         repo: myrepository
  11.         # URL of the Bitbucket Server. Required.
  12.         api: https://mycompany.bitbucket.org
  13.         # Credentials for Basic authentication. Required for private repositories.
  14.         basicAuth:
  15.           # The username to authenticate with
  16.           username: myuser
  17.           # Reference to a Secret containing the password or personal access token.
  18.           passwordRef:
  19.             secretName: mypassword
  20.             key: password
  21.       # Labels are not supported by Bitbucket Server, so filtering by label is not possible.
  22.       # Filter PRs using the source branch name. (optional)
  23.       filters:
  24.       - branchMatch: ".*-argocd"
  25.   template:
  26.   # ...
  • project: Required name of the Bitbucket project
  • repo: Required name of the Bitbucket repository.
  • api: Required URL to access the Bitbucket REST API. For the example above, an API request would be made to https://mycompany.bitbucket.org/rest/api/1.0/projects/myproject/repos/myrepository/pull-requests
  • branchMatch: Optional regexp filter which should match the source branch name. This is an alternative to labels which are not supported by Bitbucket server.

If you want to access a private repository, you must also provide the credentials for Basic auth (this is the only auth supported currently): * username: The username to authenticate with. It only needs read access to the relevant repo. * passwordRef: A Secret name and key containing the password or personal access token to use for requests.

Filters

Filters allow selecting which pull requests to generate for. Each filter can declare one or more conditions, all of which must pass. If multiple filters are present, any can match for a repository to be included. If no filters are specified, all pull requests will be processed. Currently, only a subset of filters is available when comparing with SCM provider filters.

  1. apiVersion: argoproj.io/v1alpha1
  2. kind: ApplicationSet
  3. metadata:
  4.   name: myapps
  5. spec:
  6.   generators:
  7.   - pullRequest:
  8.       # ...
  9.       # Include any pull request ending with "argocd". (optional)
  10.       filters:
  11.       - branchMatch: ".*-argocd"
  12.   template:
  13.   # ...
  • branchMatch: A regexp matched against source branch names.

GitHub and GitLab also support a labels filter.

Template

As with all generators, several keys are available for replacement in the generated application.

The following is a comprehensive Helm Application example;

  1. apiVersion: argoproj.io/v1alpha1
  2. kind: ApplicationSet
  3. metadata:
  4.   name: myapps
  5. spec:
  6.   generators:
  7.   - pullRequest:
  8.     # ...
  9.   template:
  10.     metadata:
  11.       name: 'myapp-{{branch}}-{{number}}'
  12.     spec:
  13.       source:
  14.         repoURL: 'https://github.com/myorg/myrepo.git'
  15.         targetRevision: '{{head_sha}}'
  16.         path: kubernetes/
  17.         helm:
  18.           parameters:
  19.           - name: "image.tag"
  20.             value: "pull-{{head_sha}}"
  21.       project: "my-project"
  22.       destination:
  23.         server: https://kubernetes.default.svc
  24.         namespace: default

And, here is a robust Kustomize example;

  1. apiVersion: argoproj.io/v1alpha1
  2. kind: ApplicationSet
  3. metadata:
  4.   name: myapps
  5. spec:
  6.   generators:
  7.   - pullRequest:
  8.     # ...
  9.   template:
  10.     metadata:
  11.       name: 'myapp-{{branch}}-{{number}}'
  12.     spec:
  13.       source:
  14.         repoURL: 'https://github.com/myorg/myrepo.git'
  15.         targetRevision: '{{head_sha}}'
  16.         path: kubernetes/
  17.         kustomize:
  18.           nameSuffix: {{branch}}
  19.           commonLabels:
  20.             app.kubernetes.io/instance: {{branch}}-{{number}}
  21.           images:
  22.           - ghcr.io/myorg/myrepo:{{head_sha}}
  23.       project: "my-project"
  24.       destination:
  25.         server: https://kubernetes.default.svc
  26.         namespace: default
  • number: The ID number of the pull request.
  • branch: The name of the branch of the pull request head.
  • branch_slug: The branch name will be cleaned to be conform to the DNS label standard as defined in RFC 1123, and truncated to 50 characters to give room to append/suffix-ing it with 13 more characters.
  • head_sha: This is the SHA of the head of the pull request.
  • head_short_sha: This is the short SHA of the head of the pull request (8 characters long or the length of the head SHA if it’s shorter).

Webhook Configuration

When using a Pull Request generator, the ApplicationSet controller polls every requeueAfterSeconds interval (defaulting to every 30 minutes) to detect changes. To eliminate this delay from polling, the ApplicationSet webhook server can be configured to receive webhook events, which will trigger Application generation by the Pull Request generator.

The configuration is almost the same as the one described in the Git generator, but there is one difference: if you want to use the Pull Request Generator as well, additionally configure the following settings.

Github webhook configuration

In section 1, “Create the webhook in the Git provider”, add an event so that a webhook request will be sent when a pull request is created, closed, or label changed.

Add Webhook URL with uri /api/webhook and select content-type as json Add Webhook URL

Select Let me select individual events and enable the checkbox for Pull requests.

Add Webhook

The Pull Request Generator will requeue when the next action occurs.

  • opened
  • closed
  • reopened
  • labeled
  • unlabeled
  • synchronized

For more information about each event, please refer to the official documentation.

Gitlab webhook configuration

Enable checkbox for “Merge request events” in triggers list.

Add Gitlab Webhook

The Pull Request Generator will requeue when the next action occurs.

  • open
  • close
  • reopen
  • update
  • merge

For more information about each event, please refer to the official documentation.

Lifecycle

An Application will be generated when a Pull Request is discovered when the configured criteria is met - i.e. for GitHub when a Pull Request matches the specified labels and/or pullRequestState. Application will be removed when a Pull Request no longer meets the specified criteria.