You can run custom commands prior to the build script step. I have not had a need for this step yet.
If the before_script step exits with a non-zero error code, the build is marked as error and stops immediately.
I call both my build script and test runner script here because non-zero error codes flag the build as a failure, but the build continues to run, which was what I wanted for these. There is also an
after_script section where I could have run my tests, but this step is run last, after the finalization
after_failure steps (similar to the AppVeyor
on_finish step), but also after the deploy steps. Also, these three steps do not affect the build result unless the step times out, and I wanted both the build script and the test script to affect the build result.
script: - pwsh -file ./build/shared/build.ps1 - pwsh -file ./tests/start-tests.ps1
This step is used to clean up your cache of files & folders that will persist between builds. I have not needed this yet. Again, tabula rasa.
After Success / After Failure
You can perform additional steps when your build succeeds or fails using the
after_success(such as building documentation, or deploying to a custom server) or
after_failure(such as uploading log files) options.
I chose to build my documentation in the
build.ps1 script in the script step instead of the
after_success step, because I wanted failure to affect the build result in my project.
# on successful build #after_success: # on build failure #after_failure:
There are tons of continuous deployment options available in the Deployment Configuration, such as Heroku, Engine Yard, and so many others, but I haven’t needed any for this project so far because I am handling all of the publishing from AppVeyor. The continuous deployment tasks could have been implemented just as easily from Travis CI, I just happened to finish the AppVeyor integration first and my publishing tasks only need to happen once per build.
# scripts to run before deployment #before_deploy: #deploy: #skip_cleanup: # scripts to run after deployment #after_deploy: # after build failure or success #after_script:
It took me approximately one email to get tired of build email notifications. I recommend disabling it in the Notifications section as shown below. Next, there are tons of free options out there, but I chose to create a free Slack.com workspace for monitoring builds. Travis CI has an app published in the Slack App Directory, and setup instructions can be found here.
notifications: email: false slack: secure: <secure string>
That’s it for now. I have really enjoyed using the Travis CI platform so far, and feel much more confident in the quality of my project because of it.
Enjoy!Improve this page