You will need roughly 3 minutes to read this article.
Using scripts on 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.
There are a couple options for where to store scripts used in your project.
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:
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)"
set -e in your scripts can have undesirable side effects on 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 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.
Contact our support team or post on Stack Overflow using the tag
#codeship. Did you check the status page and changelog?
There are also several code examples and sample projects available for you to get started with.