It's been a month since my last feature roundup blog post, and true to our commitment to fast innovation, Shippable has a lot of new exciting features I want to introduce today.
- A Shippable Status page
- All Amazon ECR regions supported
- Ability to customize branches shown on Subscription and Landing pages
- Code coverage alerts
- Builds for GitHub tags and releases
- Ability to customize startup commands for Services
- Pipelines: Multiple deployment environments per subscription
- Pipelines: Use images from any docker registry
- But wait, There's more!
Without further ado, let's get started:
This was easily the most frequent customer request of the past year. While other features are relevant for a subset of customers, a Status page in on everyone's wishlist. We finally have a Status page at http://status.shippable.com!
Our Status page shows the current Up/Down status for our website and API, as well as response time for the API. It also shows the status of some third party integrations so if something is not working for a particular integration, you can check and see if everything is working for that integration. Click on the image below to view our Status page!
When we announced the ability to pull and push Docker images to Amazon ECR, region
us-east-1 was the only one supported out the door. Due to popular demand for other regions, we have now added the ability to push and pull to any region as part of your continuous integration workflow by specifying it in the yml as shown below:
integrations: hub: - integrationName: your_integration_name type: ecr region: us-west-2
Your deployment pipelines can also sync your images and tags from any ECR region. Just include the fully qualified image name while creating the pipeline image and we will detect the region from the image name and sync appropriately.
You can now override our default algorithm for showing status of a project on the Subscription and Landing pages. Our algorithm is - show status of latest commit build of default branch; if no default branch, show latest commit build for master branch; if no master branch, show latest build status across branches.
This doesn't work for all customers since they want to see specific branch(es) on these pages, even if the branches are not specified as default in their source control account. This is now possible by specifying the branches you want to see for a project in the Project Settings page:
You can also configure whether you want to see status only for commit builds, or both commit and pull request builds.
Tired of waiting for 2 hours and then discovering your build timed out? You can now get faster feedback by setting a smaller timeout configuration in your Project's Settings as shown below:
Builds for your project will now timeout at the configured value and you can detect timeouts faster and take action.
You can now configure the minimum threshold percentage for code coverage per project. If any build has a lower code coverage, you will receive an alert and also have the option of marking the build unstable. Check it out in your Project Settings!
You can now choose whether you want to trigger your continuous integration workflow when you push a tag to your GitHub repository and/or create a release. This is also configured through your Project settings:
In addition, you can customize your yml to take different actions if a build is triggered for a tag or release by using our new environment variables IS_GIT_TAG, GIT_TAG_NAME, IS_RELEASE, IS_PRERELEASE, and RELEASED_AT. More on these environment variables is explained here.
For example, you could do the following in your yml:
- if [[ $IS_GIT_TAG == true ]]; then ./doSomething.sh; fi
If you want to specify your own startup command for pre-installed services, you can do so by setting the relevant environment variable in your yml. The variable name is for a service is SERVICE_*_CMD, where * is the name of the service you want to customize.
For example, you can override the default startup command for Postgres by including the SERVICE_POSTGRES_CMD environment variable as shown below:
- SHIPPABLE_POSTGRES_CMD="sudo -u postgres $SHIPPABLE_POSTGRES_BINARY -c \"config_file=/etc/postgresql/$SHIPPABLE_POSTGRES_VERSION/main/postgresql.conf\" -c \"fsync=off\" -c \"synchronous_commit=off\""
This is described in greater detail in our documentation.
When we launched Shippable pipelines earlier this year, it only supported one environment per subscription. This environment could be configured on any Container service like Amazon ECS, Google Container Engine (GKE), or Docker Cloud. The first big feature request in this area was the ability to create multiple environments and deploy to them through Shippable pipelines.
I am happy to announce that this is now available and you can set up any number of environmens in a subscription, and configure your pipelines to deploy to one or more of these environments.
You can find more details about this and pipelines in general in our documentation.
You can now add an image from any docker registry to your pipelines, including private Docker registries, Docker Trusted Registry, and Quay.io.
For private Docker registries, Shippable supports token-based authentication, which means your registry must have an auth server.
In addition to the features listed above, we also announced the following features and wrote blogs on how to use them. ICYMI, here are links to the announcement blogs:
- Build GitLab repositories with Shippable
- Automate infrastructure provisioning using terraform scripts
There are a lot of new features coming down our pipeline next month, and I can hardly wait to write the next blog. We always love to hear feedback, so try out these new features today and let us know what you think.
Au revoir and Happy Shipping until then!