Skip to content
Switch branches/tags
Go to file
Cannot retrieve contributors at this time

v6.5.1 Release Notes

Release Date

Thursday, May 24 2018


  • Node caching: Node caching is a premium feature that can be purchased for any on-demand Node SKU for an additional price of $25/node per month. If turned on, your build nodes (minions) will be paused between jobs instead of being terminated and spun up again. This will not only save node spin up time, but any dependencies or Docker images you pulled for your CI or CD workflows will be available on your nodes.

    Node caching is most useful for customers taking the following actions as part of their CI/CD workflows:

    • Using a custom Docker image
    • Pulling a Docker image
    • Building a Docker image
    • Pulling large dependencies which don't change for every job
  • Retrying failed matrix builds: If you have a CI workflow that leverages matrix builds, you might have one or two jobs in the matrix that fail due to a non-code related temporary reason, such as a network glitch, npm mirrors being down, etc. In these cases, you want to retry the failed jobs, but not necessarily the jobs that succeeded. The new Retry failed jobs option will let you do exactly that!

    To make things clear, say you have a build matrix of 5. For build # 450, you see that 450.3 and 450.4 failed, while 450.1, 450.2, and 450.5 succeeded. You click on Rerun failed jobs for build #450.

    Here is what happens:

    • A new build is spun up, let us assume it is 451.
    • All jobs that were successful (450.1, 450.2, 450.5) are simply copied over to the new build, as 451.1, 451.2, 451.5, along with their status.
    • All failing jobs (451.3, 451.4) are queued to be run again.
    • Build status for 451 is the aggregate of the jobs that were copied over plus the jobs that were run again.
    • The new build will be clearly marked as a re-run of the original build.
    • If 450 was a pull request, build #451 will overwrite the pull request status in your source control provider

    While this is immensely useful and saves time for large matrix builds, there is one small caveat. If some time passes between the original build and the rerun, the successful status for the copied over jobs might no longer be valid due to merges and other changes that might happen in that time. So if you choose to rerun only failed jobs, you might have a false sense of security. For this reason, we recommend that if a bunch of code has changed since the original build, you should rerun the whole build instead of only failed jobs.

  • SPOG UX improvements:

    • We have removed the on-hover popup for jobs and resources. Users gave us feedback that it often comes in the way when they wanted to right click on the SPOG.
    • We have implemented a compact context menu that includes all the actions that are present in the current context menu and also shows all of the information that is being shown in the on-hover popup.
  • Current AMI version is exposed as an environment variable: Using the current AMI version while pulling a shippable language image in a runSh or runCI job speeds up the execution of the job tremendously since the docker image is already available on the node. The current AMI version can be consumed as an environment variable.

    - name: container_custom_image
      type: runSh
        - TASK:
            name: custom_container_opts
                imageName: drydock/u14pytall
                imageTag: ${SHIPPABLE_AMI_VERSION}
                options: --dns= --dns=
              - echo "Checking runtime values"
              - sudo docker info
  • Enhanced shipctl to add semantic version bump functionality: We implemented a new shipctl function bump_version that can take in a semantic version string, as well as a bump type, and return the resulting string from taking the appropriate bump action on the supplied version.

      NEW_VERSION=$(shipctl bump_version v1.0.0 minor)
      echo ""
      -> v1.1.0
      FINAL_VERSION=$(shipctl bump_version v1.2.3-rc.5 final)
      echo ""
      -> v1.2.3
  • Allow for custom incoming webhooks to trigger pipeline jobs: User have asked for the ability to receive webhooks from an external service, like, to trigger a pipeline job. Today onwards, you can add a webhook resource type in your shippable yml and specify it as an input to any of your jobs.

    For more information on how to create this resource and specify it in your provider, please go here.


  • An invalid payload sent to the POST route of accountIntegration was throwing an uncaught exception. This has been fixed.
  • An invalid credit card specified in the Billing page does not show a migration in progress panel. This error is gracefully handled and users are able to continue to use the billing page to retry their last operation.
  • Version names do not overflow in job consoles page.
  • Free users can change their addon type's from On-Demand to BYON and vice-versa for a single node without adding a card.
  • The subscription node pools page auto refreshes in real time for any changes to on-demand node pools.
  • The tooltip is rendered correctly on hover over any flags in the Flags dropdown.
  • Build runs on public projects are visible to users who do not have a shippable account.
  • Rendering of long job names in the SPOG view has been improved.
  • Users can switch to all supported java versions in their Node pool runtime version by using the shipctl command pre-installed in their language image.
  • When users upgrade/downgrade their plan without changing the on-demand SKU, the runtime version for all existing node pools is not unaffected. In addition, when users buy multiple SKU's (on-demand and/or BYON), the new node pools will have latest runtime version automatically set. This will make new builds work seamlessly without needing any user invention to manually set the runtime version.
  • Manually triggered runCI jobs set triggeredBy correctly.
  • Paring secure environment variables that contain special characters like = works as expected.

Custom Nodes

  • Windows custom node initialization failure has been fixed on Nodes that do not have Docker preinstalled.

Shippable Server

  • Fixes
    • Users can run Admiral CLI without manually installing any dependent packages.
    • The Admin subscriptions page renders correctly (does not hang) and with paging for installations with a very large number of subscriptions.


To view Shippable's release history, check out our releases page on github.