The Shippable Blog

There are few occassions when Continuous Integration (CI) builds timeout. This means, a CI build failed to complete within the expected time and is now in a timeout or in an incomplete state. Until the timed out build remains in that state for 60 minutes (for free subscription plans on Shippable) or 120 minutes (for paid subscription plans on Shippable) or it is manually canceled, it can block CI build queues.

Changing the default timeout of 60 minutes (for free plans) or 120 minutes (for paid plans) will help you address this problem. In this tutorial, I'll walk you through changing the default timeout for a CI project so that you have more control over the build queues blocked due to build timeouts. 

Web hooks on source control providers, such as GitHub and Bitbucket, are commonly used to trigger actions. This is achieved by setting up integrations that listen to specific events on the source control provider, where the source control provider sends a HTTP POST payload to the web hook's configured URL. Examples include notifying a user or a channel of an event, updating an external issue tracker, deploying code to a production server and triggering Continuous Integration builds. 

In this tutorial, I'll go over configuring web hooks to trigger for five scenarios - commits, pull requests, tags, releases and temporarily pausing all web hooks to the project.

Software applications are regularly updated primarily to add new features, resolve bugs in the code and for security enhancements. A development language is no exception and each major update is called as a version. While it is a great advantage to have newer features, lesser issues and stronger security, the challenge arises when complexity creeps in. With multiple versions of a language, applications that depend on them have to be compatible with many versions. Moreover, when the applications themselves have to be updated, the combination of different versions of the language and the application makes it a challenge to write and test code.

Testing code against multiple versions of a language early in the application delivery life cycle helps in fixing errors quickly and makes testing more efficient in the downstream of the life cycle. In this tutorial, I'll go through testing a Node.js application against multiple versions of Node.js for every code commit during the continuous integration phase of the software development life cycle.

Two among the most popular source control providers are GitHub and Bitbucket. Both these providers offer free repositories and it is not uncommon for software teams to have few of their projects on GitHub and few others on Bitbucket. So if you are a developer who has accounts with both GitHub/Bitbucket and looking to run Continuous Integration on projects hosted on both of these source control providers, this tutorial will help you acheive it in an easy way.

First, let's take a brief look at how source control providers are used. Software developers use web-based, hosted source code systems for software projects, to leverage functions such as distributed revision control, bug tracking, source code management and wiki-based documentation. The source code repositories store large amounts of software source code, kept either publicly (for open source projects) or privately and enable multiple developers to collaborate on the code.

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.