Tests Configuration

Before Script

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.

#before_script:

Script

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_success and 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

Before Cache

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.

#before_cache:

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:

Deployment Configuration

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:

Notifications

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>

Conclusion

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

Comments