Getting started
IntroductionInstalled packagesEnvironment variablesDebugging buildsCachingParallel testingDeployment pipelinesRunning commands as rootIgnoring commandsRun a command in case of an errorSetting timezoneAccess to other repositoriesUsing scriptsGit LFSUbuntu 20.04 Focal
IntroductionFTP/SSH/SFTP/RSYNCCustom scriptHerokuHeroku MigrationAWS Elastic BeanstalkAWS CodeDeployAWS LambdaAWS S3Google App EngineAWS CLIgcloud CLIAzure CLIDigital OceanEngine YardCapistranoGit PushCloudFoundryCloud66anynines
IntroductionBrowser testingBackground commandsGit submodulesCustom DNSArtifacts
IntroductionCassandraCouchDBDynamoDBMongoDBMySQLPostgreSQLSQLite
IntroductionDartElixirGoJava and JVMMeteorNode.jsPHPPythonRubyRust
IntroductionBeanstalkdRabbitMQRedis
IntroductionElasticsearchMemcachedSphinx
IntroductionCloudBees CodeShip Pro introduction guideCloudBees CodeShip Pro introduction guide 2CloudBees CodeShip Pro introduction guide 3CloudBees CodeShip Pro introduction guide 4CloudBees CodeShip Pro introduction guide 5
Migrating to CloudBees CodeShip Pro
Docker for CI/CD
Getting started with CloudBees CodeShip Pro overview and resources
IntroductionServices configSteps configEnvironment variablesImage registriesImage cachingBuild argumentsVolumesHandling secretsMultiple reposServices and databasesSetting an SSH private keyPreinstalled images
IntroductionInstallationUsing the Jet CLIjet cleanupjet decryptjet encryptjet generatejet loadjet runjet stepsjet updatejet validatejet version
IntroductionAWSAWS S3AWS EBAWS ECSAWS EKSAWS CodeDeployAzure Container ServiceHerokuGoogle CloudGoogle App EngineGoogle Cloud FunctionsGoogle Container EngineGoogle Compute EngineKubernetesTerraformDeploy Via SSHDocker SwarmIBM Cloud FoundryIBM Cloud Container Service
IntroductionBrowser testingParallel testing
IntroductionElixirGoJava and JVMNode.jsPHPPythonRuby
IntroductionCaching multi-stage DockerfileContainer is slow to exitDiffering results with Jet CLIDocker Hub rate limitingManaging multiple environments for a serviceReducing log output from dependent containersStep log not appearingUsing env vars in command steps

Configuring Build Triggers

3 minute read

Triggering Builds On Commits, Merges, And Tags

You can trigger a build when committing, merging, and pushing tags to your project. This is the default behavior. See working with tags for more information on pushing tags.

To trigger a build on commit, builds and tags:

  1. Go to Project Settings.

  2. Select the Build Triggers tab.

  3. Select the Build on commit, merge, and tags radio button.

  4. Click the Save Configuration button.

Triggering Builds Only On Pull Requests

You can trigger a build when opening, merging, and updating a Pull Request (PR).

To trigger a build only on PRs:

  1. Go to Project Settings.

  2. Select the Build Triggers tab.

  3. Select the Build only on PR events radio button. Build only on PRs

  4. Click the Save Configuration button.

Note: The following environment variables are populated after the Build only on PR events configuration is saved: * CI_PR_NUMBER is populated with the pull request number. * CI_PULL_REQUEST is populated with the URL of the pull request.

See CodeShip Basic Environment Variables or CodeShip Pro Environment Variables for more information.

Triggering Builds on Commits versus on Pull Requests

The following table shows when a build is triggered.

Trigger a Build on Commit, Merge, Tags Trigger A Build On Pull Requests

Push a Commit

Yes

No

Push a Tag

Yes

No

Open a Pull Request

No

Yes

Update a Pull Request

Yes

Yes

Merge a Pull Request

Yes

Yes

Configuring Branches

You can run builds for all branches, exclude branches from triggering builds, and run builds only for certain branches. The default behavior is to run builds for all branches.

Excluding Branches From Triggering Builds

To exclude branches from triggering a build:

  1. Go to Project Settings.

  2. Select the Build Triggers tab.

  3. Select the Don’t run builds for these branches radio button.

  4. Enter either full branch names like "master" for exact matches or a regular expressions like "^release.*$" for a search pattern. Exclude branches from running builds

  5. Click the Save Configuration button.

Running Builds Only For These Branches

To run builds only on certain branches:

  1. Go to Project Settings.

  2. Select the Build Triggers tab.

  3. Select the Run build for these branches only radio button.

  4. Enter either full branch names like "master" for exact matches or a regular expressions like "^release.*$" for a search pattern.

  5. Click the Save Configuration button.

Skipping builds on the same branch

The auto-supersede feature can automatically skip builds in the queue when a newer build on the same branch comes in. By running a build based upon the latest commit, you can streamline the builds and save time. If a code change commit contains an error and a subsequent commit corrects that error, this feature can skip the build with the error and run the fixed, latest build.

The auto-supersede feature adds a new state, skipped, to the build list.

The following example shows how builds are skipped. First, you have a build that is running and another build that is queued.

Build is queue

Next, pushing a commit queues a new build. The queued build appears on the top line of the build list. CloudBees CodeShip Pro, updates the build list in real time, so the status of a build appears as skipped immediately.

Build is queue

CloudBees CodeShip Basic only updates a build status to skipped once the build had completed running. In the following, the build succeeded.

Build is queue

You can not restart a skipped build. You can view the build on your source code management (SCM) system or go to Project Settings by clicking the drop-down arrow,

To automatically skip builds on the same branch:

  1. Go to Project Settings.

  2. Select the Build Triggers tabs.

  3. Select the Auto-supersede radio button to On.

Turn on Auto-supersede

  1. Click the Save the Configuration button.

Skipping individual builds
Git remote push