-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[PAY][$250] Combine deploy.yml and platformDeploy.yml #48432
Comments
Triggered auto assignment to @sakluger ( |
auto-assigner is going to be confused here. I'll be the "C+" for this issue and @rayane-djouah will be the contributor. And we're skipping the proposal phase because we've already hashed out the solution in slack |
Job added to Upwork: https://www.upwork.com/jobs/~019fe3122b194caa3c |
Current assignee @rayane-djouah is eligible for the External assigner, not assigning anyone new. |
@rayane-djouah any update here? |
PR in progress |
@roryabraham PR ready for review |
No checklist is needed here since this is a Github Actions improvement |
@roryabraham Is there anything left to do here? |
Nope, I think we can issue payment now. Thanks for the follow-through |
@sakluger no need for a regression period, this can be paid right away |
@sakluger @roryabraham @rayane-djouah this issue is now 4 weeks old, please consider:
Thanks! |
@rayane-djouah here's the Upwork offer: https://www.upwork.com/nx/wm/offer/104233258 Please let me know once you've accepted it. |
@sakluger - Offer accepted. Thanks! |
All paid, thanks! |
@sakluger - Coming from https://expensify.slack.com/archives/C01GTK53T8Q/p1728319262830679, I haven't received my payment for this issue. Could you please look into it? Thank you! |
Hi @rayane-djouah, sorry about that, there is an Upwork bug affecting some payments. I added a $250 bonus on the original contract. Should be good to go now! |
Problem
We have started to adopt the practice of shipping checklists but skipping prod deploys when there's only a few blockers left caused by a PR we don't want to revert. This allows us to engage Applause in QA of new code on staging and to uncover and fix any other blockers lurking on main while we work on fixing the remaining known blockers on staging. As a result of this practice, we avoid building a huge backlog of un-QA'd PRs, we avoid scenarios where we have many blockers introduced to staging at once, which saves our team time (particularly for the deployer that week).
However, this practice results in broken prod deploy comments. If a checklist is shipped and the prod deploy for that checklist is skipped, then the PRs included in that checklist never receive "deployed to prod" comments, even after the next complete and successful prod deploy. This is a problem because it leads to confusion for our BZ process and makes it harder to track when payments are due to contributors.
The root cause for this problem with deploy comments in this edge case lies in getDeployPullRequestList. That action looks for the version of the last completed deploy for the given environment, and tries to enumerate all PRs between that version and the just-deployed version. It does not work in the edge case of a skipped prod deploy, because there's always a staging deploy with a matching version. When determining if a deploy matches the given environment, it looks at whether the release for that deploy is a prerelease (staging) or finalized (production). However, even if a prod deploy was skipped, that skipped deploy workflow was triggered by a finalized release. So our code mistakes the staging deploy with the same version code as the skipped prod deploy for a prod deploy.
Solution
First some background... Right now, we have two workflows involved in creating deploys.
deploy.yml
just:So to solve this problem of staging deploys being mistaken for prod deploys, we can actually combine these two workflows into a single workflow, which we'll call deploy.yml. It will:
By waiting for an actual deploy to complete before creating a release, we never have to worry about releases being associated with cancelled deploys, or about them being falsely matched with a workflow different than the one that created or finalized them.
When looking for the last completed staging deploy, we simply look at the newest release (prerelease or finalized). When looking for the last completed prod deploy, we simply look at the latest finalized release.
Upwork Automation - Do Not Edit
Issue Owner
Current Issue Owner: @The text was updated successfully, but these errors were encountered: