When a pull request is opened, Seed receives a pull request notification from GitHub. Seed will then build, test, and deploy the pull request commits automatically into a new stage. The new pull request stage will receive a unique API Gateway endpoint just like any other stage. Seed will also build and deploy to the stage when commits are added to the pull request. We currently support pull requests only for GitHub. Contact us if you’d like to use it for Bitbucket or GitLab.

Pull requests get their own unique endpoint and behave like any other stage

An important thing to note here is that the pull requests submitted to any branch that is not being tracked in Seed will not be built. This is because Seed uses the environment variables and secrets of the upstream stage to build the pull request.

Pull requests submitted to branches that are not being tracked are ignored

Let’s look at this in a bit more detail.

Enable Auto-Deploy Pull Requests

By default, auto-deploying PRs are disabled. You can enable them by heading to your app, clicking Settings, and then hitting Enable Auto-Deploy PRs.

Enable auto deploy pull requests

You also have the option here to remove the stage and the deployed resources once the PR is closed.

Auto-deploy pull request options

By default, Seed does not remove the stage and the deployed resources created as a part of the PR. But if the above option is enabled then Seed will automatically clean up all the resources that were created as a part of the pull request.

Next, let’s work through the PR workflow.

Create a PR

Create a pull request.

Create Pull Request

You’ll notice that Seed will automatically start building the PR.

Seed PR building check in GitHub

And in the Seed console you should see a new pull request stage created and building.

Pull Request Stage Building

GitHub will let you know once the PR has been built.

Seed PR building complete in GitHub

Seed also takes care of the environment variables and secrets for your pull requests. The variables defined in the serverless.yml for the upstream stage are made available to the pull request stage. Secret variables are also inherited from the upstream stage.

Environment variables and secrets of the upstream stage are automatically available to the pull request build

In the example above, the pull request was submitted to the master branch, which is tracked by the dev stage. This means that any pull requests submitted to the master branch will use environment variables set for the dev branch. And the secrets for the dev stage will also be available to the pull request build.

Say for example your serverless.yml looks like:

service: service-name

custom:
  myEnvironment:
    MESSAGE:
      production: "This is production environment"
      dev: "This is development environment"

provider:
  name: aws
  environment:
    MESSAGE: ${self:custom.myEnvironment.MESSAGE.${opt:stage}}

Any pull requests submitted to master (or the stage dev), will have the process.env.MESSAGE set to This is development environment.

Once the pull request is merged a build is automatically triggered in the upstream stage and an updated build with the merged code is created. Alternatively, you can directly promote a build from the pull request stage without merging the pull request. This is useful when you are deploying a hotfix.

You can now merge the pull request and optionally remove the PR branch by hitting Delete branch in GitHub.

GitHub delete PR branch

If you have the Remove the stage and all the resources when the PR is closed option enabled above, Seed will automatically remove the stage once the PR is closed.

Seed auto-remove PR branch

By enabling Auto-Deploy PRs, Seed makes it really easy to work with pull requests on GitHub.