You can granularly define build stages as well as conditional builds based on criteria such as branch, release tag, et cetera in the Jobs section.
I have not implemented this so far.
I recommend setting the Language to generic for scripting language projects (which is not listed in the Language documentation, but is briefly mentioned here), because all I needed for installing PowerShell Core was bash, curl, & apt for Ubuntu and homebrew for macOS, but there are a wide variety of choices if you require otherwise.
You can also define specific runtime versions for certain applications.
If more than one runtime version is specified for the same item, a job will be created for each version.
I did not need to implement any of these for this project though.
In the Git section, you can specify a clone depth limit or disable cloning of submodules to optimize job performance.
As of 20171128, the default commit depth on Travis CI is 50, which should provide sufficient commit history for most projects with accommodation for job queuing.
If you plan to test your open-source PowerShell project on multiple CI providers such as Travis CI and AppVeyor, I recommend defining a few global environment variables such as the ones listed below that abstract the CI specific variables to minimize the logic needed for handling each in your build scripts.
If you define a variable more than once, another job will be created for each definition.
You can also define matrix-specific environment variables in this section, or at the image level in the Matrix section.
You can define your build images at the global scope; however, I chose to use the matrix build image configuration as recommended here for multiple operating system build configurations, because it is cleaner.
For example, when osx_image is defined at the global scope, your Ubuntu builds will receive the xcode tag, even though it does not apply.
The Matrix section allows you to customize each image that will build your code.
I cover most of these features sufficiently in the previous post, but the two that I did not are:
allow_failures, which will permit the specified build image to pass regardless of any errors that occur.
I’ll likely never use this feature because it defeats the purpose of implementing continuous integration in my opinion.
exclude, which prevents building specified images when you define combinations of environment variables, runtime versions, and/or matrix images.
I don’t foresee my scripting language projects being complicated enough to require this feature.
You can cache files and folders to preserve them between builds such as if you have low-volatility, large files that take a while to clone.
I did not.
If the cache step exits with a non-zero error code, the build is marked as error and stops immediately.
# build cache to preserve files/folders between builds#cache:
In a before_install step, you can install additional dependencies required by your project such as Ubuntu packages or custom services.
One important thing to be aware of is that matrix image instructions override global instructions.
Since I placed the homebrew commands to install PowerShell in the Before Install step of the macOS build matrix image, if I were to define a global Before Install step, the macOS build matrix image would ignore it.
Alternatively, you could use conditional logic in the global step if you only wanted to perform some instructions on a specific operating system, and some on all build images.
If the before_install step exits with a non-zero error code, the build is marked as error and stops immediately.
As of 20171128, there is no default dependency installation step for PowerShell projects on Travis CI.
In the install step, I chose to install and import the necessary PowerShell modules on all build images, and implemented it via a PowerShell script so that I always utilize the same logic in my AppVeyor builds with no additional configuration (ie: DRY).
If the install step exits with a non-zero error code, the build is marked as error and stops immediately.
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_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.
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’m 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.