-
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
[HOLD for payment 2023-05-23] Make it so we can run E2E performance tests on any branch #15605
Comments
|
The solution for this issue has been 🚀 deployed to production 🚀 in version 1.2.78-0 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:
If no regressions arise, payment will be issued on 2023-03-13. 🎊 After the hold period is over and BZ checklist items are completed, please complete any of the applicable payments for this issue, and check them off once done.
As a reminder, here are the bonuses/penalties that should be applied for any External issue:
|
@roryabraham Uh oh! This issue is overdue by 2 days. Don't forget to update your issues! |
@roryabraham 6 days overdue. This is scarier than being forced to listen to Vogon poetry! |
Worked with ring0 to try and get this working with a larger runner here |
Some progress made today in that the jobs are running now. It seems there are some build errors, but at least now we can work on fixing them. |
One way to do this might be to do this to do the test merge locally: git checkout main
git merge --no-commit $PR_HEAD Also, we need to set the expected behavior when the PR is unmerged and has merge conflicts. I kind of think in that case we should just fail early. |
@roryabraham - Are the tests currently broken? |
yes |
What are we doing to prioritize fixing them? I think they would have caught performance regressions like: #17427 |
I posted about this here last week |
I think the tests are going to be fixed by this PR: #17569 The only issue now is that we need to wait for a deploy cycle to fix our comparison release to the PR version it compares against. |
@roryabraham The simplest solution I found to fix the issue is to use the last commit in the PR instead of the merge commit if the PR hasn't been merged yet: getPullRequestDetails.js
- core.setOutput('MERGE_COMMIT_SHA', PR.merge_commit_sha);
+ core.setOutput('MERGE_COMMIT_SHA', PR.state === 'open' ? PR.head.sha : PR.merge_commit_sha); This is enough to get the "Build APK from delta ref" job to complete successfully. I'm not sure about the AWS tests since those will always fail because I'm running the workflow from my fork (Credentials could not be loaded). I'm also testing out the "merge PR locally, then get and checkout merge commit sha" approach you mentioned, but I don't have a working solution yet. |
Update: I think the solution I posted above only worked because I was running the workflow from my fork against my own PR in the upstream repo. Running it against other PRs results in the same invalid commit error message. I tried this approach and also get the same message when trying checkout/merge the PR head commit:
Though perhaps this is because I'm running the workflow from a forked repo? In the end I managed to get it working (for branches from forked repositories) by adding the forked repo as a remote and fetching the changes before merging:
This seemed to do the trick, but after a while I started getting |
Update: I opened a PR with my solution: #17972 When running the e2e performance tests workflow for an unmerged PR, the "delta ref" is checked out and the apks are built and downloaded successfully. Examples of the workflow working correctly: All 3 workflows now fail at the
I’m not sure if I should continue working on this issue since as an external contributor I can only run the workflow from my fork, which means it will always fail at |
|
The solution for this issue has been 🚀 deployed to production 🚀 in version 1.3.14-14 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue: If no regressions arise, payment will be issued on 2023-05-23. 🎊 After the hold period is over and BZ checklist items are completed, please complete any of the applicable payments for this issue, and check them off once done.
As a reminder, here are the bonuses/penalties that should be applied for any External issue:
|
@jczekalski, @roryabraham Huh... This is 4 days overdue. Who can take care of this? |
This was completed by SWM w/o an additional bounty, so no additional payment is due here. |
If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!
Problem
When there's a performance regression on staging caught by the automated e2e performance tests, it's not always easy to trace that regression.
Sometimes, we want to just revert suspect PRs just to see if that works, but that gets messy quick if it we then revert the revert.
Solution
Make it so that we can run the E2E performance tests on any branch, not just when a PR is merged.
View all open jobs on GitHub
The text was updated successfully, but these errors were encountered: