11:45pm PST, Thursday, Jan 19, 2017

• Features

  • Added standard ENVs to runSH job environments
  • Kubernetes Integration support
  • Added Time resource type
  • Added Provision job type
  • Added Jenkins job type
  • Added service deployment for GKE
  • Create a subscription integration from account integration flow
  • SPOG visualization updates
  • Node stats for custom nodes
  • Added a section in TASK that runs irrespective of the job result in Pipelines
  • CI timeouts configurable up to 24 hours for BYON

• Server installer changes

  • Additions to the installer
  • New swarm nodes can be added without resetting existing install

• Fixes

  • Builds fail when a dynamic node fails to provision in time
  • Unable to delete custom nodes in processing state with no jobs
  • When no replica resource is specified, Shippable uses the default value
  • Duplicate entries in the CI processing screen
  • Free user token experience
  • Default foreground/background ANSI escape codes ignored
  • No documentation on enabling/disabling webhooks for a gitRepo resource
  • Logged in Bitbucket Server user runs into infinite login redirection loop

• Known Issues

  • Error running some runSH jobs with gitRepo inputs

• Added standard ENVs to runSH job environments:

  • Environment Variables for use in the TASK section of every runSH job
  • Resource Variables: These variables are added to the environment for all IN and OUT resources defined for the runSh job
  • Resource Integration Variables: When an IN resource uses a subscription integration, the fields associated with that integration are added as environment variables
  • Read more in our documentation
  • Tutorial

• Kubernetes Integration support: you can now deploy your Dockerized applications to Kubernetes Container Service. Details in our documentation. We also have a tutorial on deploying to Kubernetes

• Added Time resource type: A time resource type is used to trigger a job based on a specific day and time. This resource can be used used as an IN input for any job. Read more in our documentation

• Added Provision job type: Provision jobs are used to create objects on a supported Container service. Read more in our documentation

• Added Jenkins job type: Shippable has a special job type available that will allow you to connect your existing Jenkins job to your Shippable pipeline. Read more in our documentation

• Added service deployment for GKE: Added a second way that a loadBalancer resource can be used. It can be used as an input to a provision job to create a new load balancer in a Google Container Engine (GKE) cluster. Read more in our documentation

• Create a subscription integration from account integration flow: it now shows how to create the subscription integration when creating the account integration

• SPOG visualization updates: The UI has been simplified with the following changes:
  • Resources & Jobs tabs removed from Pipelines
    • Right click on a job to run or pause the job
    • Left click on a job to view console output for each version of the job. You can also use the trace feature to see the job's inputs, or properties to see additional information about the job
    • Right click on a resource to view latest version number
    • To see "orphaned" resources, use the arrow dropdown in the upper right to add them to the view
    • 
    • More details about jobs & resources in our documentation
  • Right clicking on a job shows actions only
  • Unused resources stack horizontally at the bottom of the SPOG
• Node stats for custom nodes: Subscriptions with custom nodes can view the CPU, Disk usage and Memory as graphs. You can access these graphs through Subscriptions Settings>Nodes section>Click on the node>Stats section
  • 
• Added a section in TASK that runs irrespective of the job result in Pipelines: In pipelines, a section called Always is added to TASK that can be used to run irrespective of the job result. See an example of using this section for job notifications
• CI timeouts configurable up to 24 hours for BYON: Subscriptions with custom nodes (BYON) can set the CI timeout for projects up to 24 hours

• Additions to the installer: The following features have been added to the installer:

  • New core service called logup: This new service will upload logs of completed jobs to S3. NOTE: This service is disabled by default. This includes the following changes in usr/state.json:
    • steps.provision added to .systemSettings.rootQueueList. This creates a queue for the newly added Provision job type
    • core.logup added to .systemSettings.rootQueueList
    • A systemIntegration of masterType cloudproviders and masterName AWS added
    • A new field called rootS3Bucket in .systemSettings is added. The value is the name of the bucket where logs will be stored. If the bucket isn't already created, it will be created.
  • New fields added to systemConfig objects: in the state.json file, in systemSettings section:
    • wwwPort, redisUrl, awsAccountId, jobConsoleBatchSize, jobConsoleBufferTimeInterval, defaultCronLoopHours, apiRetryInterval, vortexUrl, truck, hubspotTimeLimit, hubspotListId and hubspotShouldSimulate.
    • In which, "jobConsoleBatchSize": 10, "jobConsoleBufferTimeInterval": 3000,.
    • wwwPort, redisUrl,jobConsoleBatchSize, jobConsoleBufferTimeInterval, defaultCronLoopHours, apiRetryInterval, vortexUrl, truck are not null fields. Where as awsAccountId, hubspotTimeLimit, hubspotListId and hubspotShouldSimulate are nullable fields.
    • Value of awsAccountId should be taken from existing envs of www: AWS_ACCOUNT_ID.
    • Value of defaultCronLoopHours should be taken from existing envs of cron: DEFAULT_CRON_LOOP_HOURS.

• New swarm nodes can be added without resetting existing install: Steps to add a new swarm node:

  • Update usr/machines.json file to add a new entry in the array.

    {
      "group": "services",
      "ip" : "<ip of machine>",
      "name": "<name of machine>", //should not be the same as any existing machine
      "login": "root",
      "dataMount": "/usr",
      "cores": 2,
      "memory": 4096,
      "arch": "x86"
    }
    

  • Run installer ./base.sh --release <version>

  • Installer will ask user to run a command on the new machine

  • Run that command and type Y in the installer prompt

  • Installer will add the new machine as a ms (MicroService) host and install Docker on it without re-initializing the existing cluster

• Builds fail when a dynamic node fails to provision in time: If for some reason the job gets stuck due to a dynamic node that failed to provision, we re-provision the dynamic nodes. Ideally a node should come up in about 3 minutes and should start processing your jobs. In case the node doesn't come up even after 10 minutes, we delete that node and re-provision another one
• Unable to delete custom nodes in processing state with no jobs: The Delete button is enabled for custom nodes that get stuck in a 'Processing' state when no jobs are processing. User will not be able to delete a custom node when it is processing a CI or a Pipeline job
• When no replica resource is specified, Shippable uses the default value: When no replica resource is specified, the replica count is no longer set to 1 when updating a service with a new task definition
• Duplicate entries in the CI processing screen: The fix resolves the issue and duplicate entries are no longer seen
• Free user token experience: UI shows if an API Token is a free token and provides link to documentation with more details

- **Default foreground/background ANSI escape codes ignored**: Handling of default foreground/background ANSI escape codes fixed - **No documentation on enabling/disabling webhooks for a gitRepo resource**: [Documentation](http://docs.shippable.com/pipelines/resources/gitRepo/) updated to include `branches` and the options to enable and disable different types of webhooks - **Logged in Bitbucket Server user runs into infinite login redirection loop**: A bug in the URL redirection caused this loop. The fix resolves this issue

• Error running some runSH jobs with gitRepo inputs: A manually triggered runSH job fails at the 'TASK' step. There's no warning in the logs. rSync job also shows a similar failure with no warning in the log.
  • Workaround: The job runs successfully by making a dummy commit to the gitRepo listed as an IN