Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Set a git ref when a deploy is successful. #917
To support future features, we want to add a per-environment per-project git reference that will allow new tools and features to know which commit is currently deployed by making a Github
See Shopify/shipit#743 for more context.
The basic gist of these changes is that when a deploy finishes, its
For now, we've assumed that it is sufficient to abide by a ref set at the end of a deploy, and not add things like startup checks by the stacks the ensure the currently set ref is correct (and so on). The idea being that it is fine to let an assumedly-rare edge case of stale or incorrect last deployed refs self-correct via deploys or manual intervention for now.
This should serve to resolve Shopify/shipit#743.
Yeah, I was able to test with Shipit running locally using a stack based on a personal project branch.
This led to me discovering the issue fixed with commit
That said, even when
I realized there's a flaw in what I've written in c3b669c - it could, in theory, retrieve a deploy other than the one that enqueued the job.
That alone isn't a problem and, in fact, ensures better behaviour of only updating with the latest sha. However, it's technically possible that a different, unsuccessful deploy could have occurred between the job being enqueued and the job firing. This would result in an incorrect ref being set.
I'm preparing a change (now: 82b2c23) that has the deploy provide the job with its own
However, something I'm now wondering about is if we want the ref to be updated for other Completed deploy statuses (such as Faulty, etc.). Those environments will technically be running new changes. But on the other hand, maybe we don't want to signal to other tools/features that they should be using the new commit in those cases? @JackTLi @DazWorrall what do you guys think?
That is, should I change
after_transition to: :success, do: :update_latest_deployed_ref
to something like
after_transition to: %i(success flapping faulty validating), do: :update_latest_deployed_ref
EDIT: Talked to Jack directly, we explicitly only want this happening on success, so I'll leave it as-is.
hm I'm a little lost on the change to include the
For posterity, we discussed Jack's comment above offline:
But this ran the risk of failed deploys' SHAs being picked up, etc. Filtering seemed long-in-the-tooth compared to just passing the sha from the deploy triggering the job.
However, when discussing this it seemed that it was better to just make the filtered call
stack_sha = stack.deploys.where(status: "success").last&.until_commit&.sha
in the job, ensuring that it is correct even if it's a bit ugly, rather than run into potential issues due to staleness or ordering concerns. So I've now gone down that route, and added a test that checks that failed deploy SHAs are not sent to github.
As a sidenote, we also came to the conclusion that, due to rollbacks needing to update the ref, we'll let Octokit force the update_ref call via
casperisfine left a comment
One thing I'd suggest though would be to make this opt-in. Because many CI system will trigger a build on new branch created (no longer a problem with buildkite), and people might want to have a specific branch name.