- Getting Started
- Example deployment to Heroku
- Using pipelines
- Deploying with Snap
- How do I add SSH keys to my build?
- Scheduling and skipping builds
- Deleting or cancelling a build run
- Billing owner best practices
- Deployment Pipeline
- The CI Environment
- Snap CI's Stacks
- Simple Docker pipeline using Snap CI
- Building & propagating Docker images
- Deploying Docker images
- Docker FAQ
- Known Limitations
- Relational Databases
- NoSQL Datastores
- Testing with browsers
- Complete Package List
- Environment Variables
- Heroku Deployments
- Deploying to AWS
- Deploying to AWS OpsWorks
- Deploying to AWS S3
- Deploying to AWS ElasticBeanstalk
- Working with Branches
- Cloning a pipeline
- Integration pipelines
- Automatic branch tracking
- Pull Requests
- Configuring multiple workers
- Speeding up builds
- Setting up test parallelism
- Pipeline Parallelism
- Polling project status using CCTray
- Webhook notifications
- How Snap integrates with GitHub
- Revoking privileges granted to Snap CI
- Managing membership
- Triggering Pipelines and Stages
- Migration to GoCD
- Migration to other CI and CD tools
For any repository that is building on Snap CI, creating a new pull request on GitHub will create a project in Snap that will actively track that pull request, and update the status on the pull request on GitHub.
How Pull Requests are tested
When a new pull request is opened or when additional commits are published on a pull request on GitHub, Snap CI is notified about it. Snap then performs a build for each of these notifications.
After each commit on the pull request is recieved, Snap will update the status on GitHub for each of the commits.
Rather than test the commits from the head on the pull request, Snap performs a merge between the pull request HEAD and the upstream branch against which the pull request is issued.
Security considerations when testing Pull Requests
In order to ensure that credentials and other sensitive information is not accidentally leaked out, Snap will, by default, ensure that no secure environment variables, secure files or other secure credentials are provided to the build for pull requests submitted from a fork of your repository. If you'd like to change any pull request settings, please visit the settings page of your build.
This is done in order to ensure that a malacious user submitting a pull request does not end up exposing this secure data.
If your build would like to know if it is running a pull request, so
that it can enable or disable certain tests, you may use the
SNAP_PULL_REQUEST_NUMBER which will contain the
pull request number if one is available.
My Pull Request is not being built
This may happen because the pull request cannot be merged, if this is the case, rebasing to ensure that the pull request merges cleanly works well.
Rerunning a pull request build
Rerunning a pull request build will ensure that the pull request HEAD is again merged with the latest upstream branch to ensure that the pull request is good.