chore: only use cypress.io when triggered manually #29077
Conversation
github-actions
bot
added
the
github_actions
mistercrunch
changed the title
ok so --parallel is a paid feature, seems we'll have to find some other way to segment/parallelize |
|
Doing it on |
|
I think I'm finding a solution. Turns out cypress doesn't do much of the compute/work here, and the dashboard is not super useful, so I'm moving to trigger the dashboard manually using workflow_dispatch, only when useful. The other thing is the parallelization is also part of the service, and it's "intelligent" meaning it know about recent runs and tries to balance / segment the jobs properly. I've been workign with GPT at segmenting the files based on a hash of the filename, so as long as we don't have some files much bigger than other it should distribute all write. If not we can just break down the slower files into smaller chunks. |
mistercrunch
requested review from
villebro,
geido,
eschutho and
rusackas
as code owners
mistercrunch
requested review from
betodealmeida,
nytai,
craig-rueda,
john-bodley,
kgabryje and
dpgaspar
as code owners
scripts/cypress_run.py
Outdated
| # Run using cypress.io service | ||
| cypress_record_key = ( | ||
| subprocess.check_output( | ||
| ["echo", os.getenv("CYPRESS_KEY") or "DUMMY", "|", "base64", "--decode"] |
There was a problem hiding this comment.
Whenever there's an action that runs a script, and the script uses a KEY, it raises my security flag now :) CC @dpgaspar to make sure this is OK :)
There was a problem hiding this comment.
this is triggered by pull_request GHA so should be ok, and I'm assuming CYPRESS_KEY is not a secret right?
yes script can be "abused" by a PR but will it have privileges to do anything destructive?
There was a problem hiding this comment.
I think not, I didn't realize the key is public.
| # leaving the Dashboard hanging ... | ||
| # https://github.com/cypress-io/github-action/issues/48 | ||
| fail-fast: false | ||
| matrix: | ||
| containers: [1, 2, 3] | ||
| parallel_id: [0, 1, 2, 3, 4, 5] |
There was a problem hiding this comment.
FWIW, since the setup for these runners takes a while, I was keeping the number of workers low enough to see a higher ROI on parallelization. This might shave off a minute or two, but will burn twice the coal.
There was a problem hiding this comment.
right, there's like 7 minutes of setup and in aggregate maybe 45 minutes of parallelizable stuff. At 6 workers it's about 50/50 of the time on overhead VS work. I thought bumping this up made some sense as it has now become the bottleneck as the longest CI workflow.
There was a problem hiding this comment.
One thing that could be nice would be to have a single worker prepare some stuff for the matrix as a whole, so that overhead could remain 7 minutes, but not be done on N workers... Not sure what GHA offers around that.
| submodules: recursive | ||
| - name: Checkout using PR ID (workflow_dispatch) | ||
| if: github.event_name == 'workflow_dispatch' && github.event.inputs.pr_id != '' | ||
| uses: actions/checkout@v2 |
mistercrunch
added
🏷️ bot
Preset is picking up the bill for Cypress.io and it's getting pricey for the usage we have for it. In this PR, I'm moving normal pull_request and push events to run in local GHA mode without the
--recordflag. This means we can't use the--parallelfeature, but I wrote a little python script that segments the jobs and make them run in parallel.I'm also providing a
workflow_dispatchoption where you can trigger a cypress.io run in dashboard mode, so you can still go use their stuff on a given branch if/where needed.