Sometimes intermittent network issues happen to the best of us, and it is particularly frustrating if it happens in the middle of a software install.
Even with the best continuous integration platform on the planet, you will still have scenarios when you want to trigger custom workflows after your CI finishes. These workflows could be very targeted and should have the ability to be customized based on whether CI passed.
Today, I am going to introduce you to a very versatile feature we added recently - the ability to add a custom webhook to your CI workflows that will be triggered after your build finishes. You can configure this trigger based on several factors, including build result, branch, etc and also include one or more parameters.
This new feature is documented here in greater detail.
Let's look at a simple example to see how this works. I have a project manishas/sample_nodejs and I want to open a GitHub issue in the repository if my build fails. I also want to customize the issue title and description to include a the project name, build number, commit message, and build URL.
In my previous blogs, I completed running a basic Continuous Integration (CI) on a Node.js app hosted on a public repository. Next, I configured a simple unit test for the Node.js app to check for errors each time I did a code commit.
In this tutorial, I'll cover running CI for the same Node.js application, if it were hosted on a private repository. Hosting code on a private repository source control system is the common way developers/teams operate during software development. The overview of the work flow is to sign in using source control provider credentials, authorizing a one-time access to private repositories, enabling the project, configuring the
shippable.ymlfile, completing a successful CI run for the Node.js app.
In the previous tutorial, I ran a basic Continuous Integration (CI) on a Node.js application. As the next logical step, I'll configure a simple unit test to check for errors in my code. As per the guidelines of CI, my expectation is that for every code commit or pull request, this unit test runs automatically and immediately checks for errors. In this tutorial I will set up a unit test, configure the
shippable.yml, and verify the unit test to complete a successful CI.
Today, we are proud to announce our latest Shippable release. This release is very close to our hearts for several reasons. First, it addresses almost all customer feedback that we have received over the last couple of years. Second, it achieves our goal of going beyond CI and being a true end-to-end continuous delivery platform for all applications. Third, our platform architecture sets us up to execute faster than anyone else, which means we can innovate at breakneck speed and deliver value to our customers, namely, YOU.
The new Shippable helps you ship code faster than ever before. Let’s delve deeper into what we are launching today.