Pull request reviews & self-apply
Much of the work on your platform happens through pull requests on your GitHub repository, written either by us or by your own team. When your team opens a PR, a Skyscrapers engineer reviews it before the change goes live. This page explains how to get that review and how we can help your team work more autonomously.
How to request a review
Start with the PR itself. Describe what you are changing and why. If that context is clear, you do not need a separate support request.
What we do need is to know the PR is there. Choose whichever suits you best:
- Add a support request on your board, linking to the PR (cfr. Create requests). Use this when your change needs more context, a delivery date or planning on our side. It also keeps progress visible to both teams.
- Ping us in Slack: start a thread in your dedicated channel and trigger Pylon with the 🎫 icon. Handy when you did not create a support request, as it puts the PR straight in front of our first-line contact.
Note
Is the review blocking your team or your end-users? Let us know through Slack, so we can pick it up as an Urgent request (cfr. Request priority).
Whichever channel you choose, please give us the real priority. We act on the priority you give us, so an Urgent request means pulling an engineer off the sprint we planned together, with the risk that other committed work slips to a later week. That’s worth doing when something is genuinely blocking. But when everything is marked Urgent, our regular planning stops being reliable: the work at risk of slipping is usually your own and the reviews that truly cannot wait become harder to spot.
A review request follows the same flow as any other request, so one you create today goes into planning first and is not automatically part of this week’s sprint (cfr. Follow up on requests).
What we look at when reviewing a PR
We check your change against the platform patterns we maintain for you: security and access, resilience, cost and whether the plan output matches what the PR sets out to do. We will also flag when a change needs a coordinated rollout instead of a plain apply.
After the review we apply the change and merge the PR, unless your team has self-apply access through Atlantis.
Applying changes yourself with Atlantis
Want to move faster on your own infrastructure changes? We can give your team apply access through Atlantis, so you run atlantis plan and atlantis apply from PR comments instead of waiting for one of our engineers. A Skyscrapers engineer still reviews the code before it is merged.
Access is granted per customer, to an approved list of GitHub users. To get started, talk to your Customer Lead or open a request on your GitHub board. The conditions your team agrees to are described in the Atlantis Self-Apply Agreement and the announcement post covers how the feature works.