Buildpack upgrades are done separately from platform upgrades because they can impact directly on tenant apps. They are also done on a regular cadence.
We give at least a week’s notice to tenants about buildpack upgrades. If the new version of any buildpack will remove an important version of a language, such as a long term support version, we should give a minimum of two weeks notice.
A PR for the upgrade is automatically created on the first of the month at 9:00 a.m. UTC. There will also be a Slack notification about this.
Once the buildpack-upgrading PR has been created in the paas-cf repo, the engineer on support should do the following:
- Create a Pivotal story to track the progress of this update.
- Checkout the PR branch locally and run
scripts/create_buildpack_email.sh, supplying highlights section by section when prompted by the script. Highlights are e.g. breaking changes, version deprecations, new versions etc. Please note that the changelog generated by the script is reflecting the most recent buildpack upgrades available, so the script should be run close in time to the generation of the PR. If it was delayed, adjusting the email for the changes included in the PR may be necessary.
- Ensure the date quoted in the email gives at least 1 weeks notice from the day the email goes out, or 2 weeks for major language changes.
- Get someone to review the email draft you generated.
- Send out the tenant comms copy via the Google Groups interface. Emails should have the subject “GOV.UK PaaS - Upcoming buildpack upgrades - $DATE”, where $DATE is in the format “11th September 2019”
- Send the email copy in our Slack channels: #paas in GDS Slack, #govuk-paas in x-gov Slack
- Mark the story as blocked with a blocker in the form
- Progress the story so that the PR can be reviewed by an engineer.
- Wait until the given date, then merge the PR to upgrade the buildpacks