Consume the reusable workflows from upbound/uptest@standard-runners #1180
Conversation
|
So, from the output of https://github.com/upbound/provider-aws/actions/runs/8084771313, the remaining unknowns are the |
|
A relatively heavyweight
Update: This This could imply we will hit similar issues for the |
|
An |
|
Looks like running the
|
|
Looks like the |
- This will also allow us to check whether any CI jobs need larger runners in the official provider repositories. Signed-off-by: Alper Rifat Ulucinar <[email protected]>
ulucinar
force-pushed
the
no-large-runners
branch
from
b14cc99 to
a0b7ea5
Compare
Signed-off-by: Alper Rifat Ulucinar <[email protected]>
Description of your changes
Relevant PR: upbound/official-providers-ci#184
This PR replaces the larger runners we are using for the:
e2e,publish-service-artifactsworkflowslint,publish-artifactsjobsto the standard
ubuntu-22.04workflow runners. This will also allow us to check whether any CI jobs need larger runners in this repo.Unfortunately, the
e2eworkflow (uptest) running on the standard runner cannot be tested with this PR. I'm planning to test thee2eworkflow on a separate repository. We have switched to the family providers inuptestruns, so I hope there's no need for the larger runners foruptestruns. This also depends on the time given to thee2eworkflow and the resource providers needed to run a test.Another test we need to do is the
publish-service-artifactsworkflow that we use to build the family packages and push them to the Upbound package registry. Building and pushing a larger number of provider packages from a single job requires more resources on the runner. Another parameter affecting the compute resources we consume on the workflow runners is the package size and recently, we have reduced the resource provider package size considerably by removing the Terraform CLI and Terraform provider. Although we have control over how many provider packages will be processed per CI child action, increasing the child action count increases the load on the package registry, as these children are currently run in parallel. We could run these child actions sequentially if needed, at the expense of increased release build & push time. We would like to experiment on these parameters using the standard runners once this PR is merged.Another job of interest is the
local-deployjob as it builds and deploys the monolith on a kind cluster. The monolith is heavy on the CPU and the memory the API server process consumes. We will be able to test it with this PR.This PR also enables the
Cleanup Diskstep for the jobs ine2e&CIworkflows.Btw, the
lintjob is already failing on the largerUbuntu-Jumbo-Runnerworkflow runner because currently it consumes ~40GB of memory. So it should fail with the smaller standard runners that we are switching to with this PR. We are working on this. This PR is for checking the rest of the CI jobs on the standard runners.I have:
make reviewable testto ensure this PR is ready for review.How has this code been tested
Tested via the following CI run: https://github.com/upbound/provider-aws/actions/runs/8248588907/job/22559239426?pr=1180