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

Using scripts

2 minute read

Using scripts on CloudBees CodeShip Basic is a great way to customize and further automate tasks in your builds. Scripts can be used in a variety of ways from build setup to deployments. We also have a repository of scripts that help with various package installations and deployments. These scripts are also great starting points for writing your own customizations.

Storing and Calling Scripts

There are a couple options for where to store scripts used in your project.

Your Repository

The most common option is to store them directly in your repository so that the scripts are under source control just like the rest of your project.

Once it is part of your repository there are a couple interchangeable ways to call the script in the build assuming you are doing some kind of Bash/shell scripting:

./path/to/script.sh

bash path/to/script.sh
▼

If your script is exporting any environment variables that need to be available to other steps in your build you will need to source the script:

source path/to/script.sh
▼

Remote Server

Another option is for your scripts to reside in a remote location. This could be a private server, a different repository or even a simple Gist. The scripts in our repository also fall into this category.

You can call a remote script from your build using curl:

curl -sSL https://raw.githubusercontent.com/codeship/scripts/master/packages/firefox.sh | bash -s
▼

Again, if the script is exporting any variables you need to source it:

source /dev/stdin <<< "$(curl -sSL https://raw.githubusercontent.com/codeship/scripts/master/languages/go.sh)"
▼

Notes And Known Issues

set -e

Using set -e in your scripts can have undesirable side effects on CloudBees CodeShip Basic if called incorrectly. You should only use set -e in a script you are calling directly. It should not be used in scripts that you are sourcing and it should also not be used directly on CloudBees CodeShip as a build step.

By default the shell doesn’t exit after a failed command, but continues to run other commands until the script finishes and then returns with the exit code of the last run command.

A script like the following will always return with an exit code of 0. Therefore if an error occurs earlier in the script, it may not be obvious in the build logs and the build will still pass.

#!/bin/sh

# Simulate two commands, one exits with a 0 exit code, the other does not
# Run them in a subshell via $(command) to simulate actually running an external command
$(exit 255)
$(exit 0)
▼

In a shell script you can use set -e to exit after the first failing command. This option will exit immediately if a command exits with a non-zero status. A script like the following will exit with an exit code of 255.

#!/bin/sh
set -e

$(exit 255)
# Will never reach this line
$(exit 0)
▼

It is safe and recommended to use set -e directly in your scripts, but again you cannot use set -e in sourced scripts or directly as a build step. This is because the option will cause the process that called the command to exit if there is an error in the script. In this case that is the SSH session which is used to control your build. From CodeShip’s view the build container has terminated and the build will fail.

Access to other repositories
Git LFS