Enable pytest on GitHub Actions and other CICD improvements #8731
Conversation
6203d8d to
7c2d060
Compare
|
Unsure why but https://github.com/qld-gov-au/ckan/actions/runs/13982496360 is getting green but this run is getting a failure. Is it possible to 'retry' the workflow on that file job. |
|
Re limits mentioned during the call, AFAICT public repos have unlimited Github Actions minutes: Our usage: Usage is shared across all org, other than core and the extensions tests we have actions to publish Docker images (a nightly run for master), and packages but these are only run on releases. Other than that there are monitors for extensions and Python versions I'm generally +1 on migrating to Github actions |
|
It's confusing that it says both "minutes are free for public repositories" and "2000 minutes/month free for public repositories" Which is it? I see that we used 3,287 minutes last month without the Python CI on github. Those minutes aren't showing up as usage right now but is is going to stay that way? What about when we're using 10k or more minutes per month? |
I think this is just a flaky test; it failed in circle CI on another PR then worked when I reran it. |
|
With my discussions around enterprise github as well as my own org usage where we are forced to move a repo private. When a Repo is private, that is when things start to 'cost'. When public/public. At this time its a ok. If GitHub does change their model for Public/Open Source repo's. Then we should hopefully have another CICD supplier coming around to drop onto. Speaking of such items. With how Docker Hub has been cheeky with their container download limits which was suppose to start march 1st but was rapidly reversed. https://news.ycombinator.com/item?id=43125089 We should also look at other places to retrieve the ckan container images. GitHub has such availability but you do need to use an auth token to download from their package management platform. |
* Merge all testing under one parent workflow * Pytest now runs and is split into 12 to run in under 3 mins (vs 10min for only 4 workers) * Allow dynamic splits to be passed in * Retieve and store latest pytest time stats for even splits * Allow individual workflows to still be callable (manually) * Allow pytest to run in single instance mode to generate test duration time data for improved splits * Uplift codeql-analysis workflow to v2
…least 3 times with 1 second dely
d7551cf to
70a9425
Compare
|
Hi @amercader @wardi, I've polished this alot more and got it to now auto generate the pytest timing file per individual split run which is then merged and stored for future runs. We should 'ad-hoc' download this file and include back into the repo (gzipped) as the fallback. This also now includes the pytest-retry and i've marked the 'flaking' test to give it a couple more retries before failing that segment. With this work, we now have a single entry on a commit/PR instead of multiples independant workflows you need to look at individual. If at a later date we want to 'enforce' Flake8 and PyRight before running the full list, we can (saying that flake8 is a good contender as its super fast but PyRight takes nearly as long as pytest to complete). 12 is a good split for speed as it now finishes pytest testing nearly at the same time as cypress. |
|
Towncrier check has seemingly got confused as the changelog entry was there before force push and then it was added again. |
|
raised #8744 to fix towncrier bug. |
|
I'm closing this PR and made a 'fresh' PR to fix up the 'confused' towncrier. See #8744 |
Fixes #8730
Proposed fixes:
Features:
Please [X] all the boxes above that apply