Skip to content
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

No concurrent builds of multi arch CLI runs #1000

Open
jakobmoellerdev opened this issue Oct 22, 2024 · 0 comments
Open

No concurrent builds of multi arch CLI runs #1000

jakobmoellerdev opened this issue Oct 22, 2024 · 0 comments
Assignees
Labels

Comments

@jakobmoellerdev
Copy link
Contributor

What happened:

Whenever we build the CLI, we build our architectures one by one. Because they dont share a build cache for large sections, we should concurrently run these compilations and let the bottleneck be the runner that we compile on.

What you expected to happen:

I expect all make steps for compilation to run with make -j for parallelization through make, and all shell scripts with a for loop for compilation through archs to run via a forked process through & and wait chaining

How to reproduce it (as minimally and precisely as possible):

Call make build or make ctf on any component

Anything else we need to know:

Environment:

@jakobmoellerdev jakobmoellerdev self-assigned this Oct 22, 2024
@github-actions github-actions bot added the area/ipcei IPCEI-CIS label Oct 22, 2024
jakobmoellerdev added a commit that referenced this issue Nov 4, 2024
…ncurrency (#996)

Our caches are getting too big:

```
Approaching total cache storage limit (58.09 GB of 10 GB Used)
```

On top we dont make use of makes inbuilt parallelism (`-j`) and also we
do not make use of shells forking mechanism for concurrent execution
(`&` execution chain followed by `wait`)

<!-- markdownlint-disable MD041 -->
#### What this PR does / why we need it

Limits the cache save to only the main branch in the build step, all
other branches/PRs and Jobs will reuse that cache instead of computing
their own

What does this mean:

PRO:
- only one cache that should roundabout have 4 (build files for all
platforms) + 2 (build+test files for unit tests on amd64) Gi of modules
and builds that get updated on every commit to main
- The build cache is likely unaffected or largely still valid for most
if not every PR. This leads to compile time improvements upwards of 600%
depending on PR size without killing our cache usage.

CON:
- a rebuild or dependency changes will be able to "invalidate" that
cache and could lead to longer build times faster. However in general,
most builds should still perform the same. If the go.mod / go.sum is not
touched, the build cache will be restored for all files except the ones
touched or impacted by the PR.

#### Which issue(s) this PR fixes
<!--
Usage: `Fixes #<issue number>`, or `Fixes (paste link of issue)`.
-->
fix #999 #1000

---------

Co-authored-by: Hilmar Falkenberg <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: 🆕 ToDo
Development

No branches or pull requests

1 participant