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

Update build workflow #1608

Merged
merged 14 commits into from
Nov 21, 2024
Merged

Conversation

mickflemm
Copy link
Contributor

@mickflemm mickflemm commented Nov 2, 2024

This series aims to improve the current build workflow as suggested in #1591.

It's better to use ubuntu-latest to track current LTS provided by github, instead of having to manually update it.
It also makes more sense to stick to the current LTS than trying to support the older one.

Signed-off-by: Nick Kossifidis <[email protected]>
This is usefull for testing / debugging.

Signed-off-by: Nick Kossifidis <[email protected]>
@TommyMurphyTM1234
Copy link
Collaborator

It's better to use ubuntu-latest to track current LTS provided by github, instead of having to manually update it. It also makes more sense to stick to the current LTS than trying to support the older one.

I thought that it was a deliberate decision to build for the most recent two LTS versions of Ubuntu? E.g.:

I'm not objecting to the switch to just ubuntu-latest but just pointing this out in case it's important.

@mickflemm
Copy link
Contributor Author

It's better to use ubuntu-latest to track current LTS provided by github, instead of having to manually update it. It also makes more sense to stick to the current LTS than trying to support the older one.

I thought that it was a deliberate decision to build for the most recent two LTS versions of Ubuntu? E.g.:

* [CI: Drop Ubuntu 20.04 and add Ubuntu 24.04 #1570](https://github.com/riscv-collab/riscv-gnu-toolchain/pull/1570)

* [Switch from Ubuntu 20.04 LTS to 22.04 LTS for jobs #1353](https://github.com/riscv-collab/riscv-gnu-toolchain/pull/1353)

I'm not objecting to the switch to just ubuntu-latest but just pointing this out in case it's important.

From both examples it seems this approach doesn't work well, things break since the repos used here are much more recent than the older ubuntu LTS, and sometimes their build process depends on recent tools and libraries, that are either not present on the older LTS or behave differently. The current build workflow already has exceptions for the older LTS, test-sim is only built for the current LTS, and make report also works only on current LTS.

I think it's better to just stick to the current LTS, and even use the ubuntu-latest label so that we don't need to update the yaml files with ubuntu version numbers everytime we get a new LTS.

@TommyMurphyTM1234
Copy link
Collaborator

Thanks @mickflemm, I'm fine with that but just wondered if dropping the "two most recent LTS versions" approach might have unintended consequences. Maybe @cmuellner might know and/or be able to sign off on this change?

@mickflemm
Copy link
Contributor Author

I'll do some more tests and then update the night release script as well to also do caching etc...

mickflemm and others added 12 commits November 9, 2024 19:55
Greatly reduces the time it takes to checkout the various submodules, and also reduces required storage.

Signed-off-by: Nick Kossifidis <[email protected]>
There are lots of things we can remove from the base image but
the list becomes long and it polutes the workflow file, so it
makes more sense to do this on a script instead. This gives
us up to 50GB of free space, and we don't have to wait for it to
finish, we can let those rm commands run in the background and
move forward with the rest of the build process.

Signed-off-by: Nick Kossifidis <[email protected]>
Saves time by cloning the submodules only once per workflow run.
This is also safer since some repos may block us if we attempt to clone
multiple times (also in parallel) during the workflow.

Signed-off-by: Nick Kossifidis <[email protected]>
We have 14GB on /mnt available (more in practice) that we don't use at all.
Instead of installing the toolchain / downloading artifacts in /opt thats
in root partition, use /mnt instead. This patch also assigns ownership
of that folder to the runner user, so that we drop use of sudo for make
later on.

Signed-off-by: Nick Kossifidis <[email protected]>
Since the runner user owns the prefix dir, there is no need to use sudo.

Signed-off-by: Nick Kossifidis <[email protected]>
Currently we create the tarball after make report which results having
qemu (both for 32 and 64bit), dejagnu, qemu etc in there too. Qemu ends
up in the nightly releases too, with its roms etc, so clean that up too.

Signed-off-by: Nick Kossifidis <[email protected]>
There are files in the output that are the same with e.g. different names on
different paths etc (and are not symlinks). Switch them to hardlinks so that tar
doesn't archive them multiple times. This could be usefull to users too, since they
may chose to preserve hardlinks when unpacking the tarball.

Signed-off-by: Nick Kossifidis <[email protected]>
Switch to xz from gzip, since it has a much better compress ratio.

Signed-off-by: Nick Kossifidis <[email protected]>
This reverts commit 5ac342c.

It seems they haven't switched to 24.04 yet:
actions/runner-images#10636
Leave it as-is for now and we can revisit this if needed.

Signed-off-by: Nick Kossifidis <[email protected]>
Although it only takes a few minutes to do the shallow clones, and we
don't trigger runs that frequently, let's keep the submodule cache
around, and invalidate it based on the hash of the 'git submodules'
command, instead on each run. This will save us space on the repo's
cache storage (10GB) and speed up the process a bit.

Signed-off-by: Nick Kossifidis <[email protected]>
This doesn't make sense anymore, it's not that we'll use any more space
at that point, it may take up to a minute to complete, clean it up.

Signed-off-by: Nick Kossifidis <[email protected]>
@kito-cheng
Copy link
Collaborator

I see the only controversial point has gone - the ubuntu version stuffs, so I am happy to moving this forward :)

@kito-cheng kito-cheng merged commit 20f6153 into riscv-collab:master Nov 21, 2024
27 checks passed
@kito-cheng
Copy link
Collaborator

@mickflemm thank you!!!

@mickflemm
Copy link
Contributor Author

Thanks @kito-cheng !

@TommyMurphyTM1234
Copy link
Collaborator

TommyMurphyTM1234 commented Dec 22, 2024

Rather than opening a new issue/PR yet I'll pose this question here...

Might there be an argument for further modifying the build workflow so that it uses -g0 to omit debug information for the toolchain host binaries and also strip the resulting binaries (or modify the riscv-gnu-toolchain top level Makefile so that it can optionally use make install-strip or equivalent for relevant submodule components?), thus reducing the size of the resulting toolchain by about 75%, maybe speeding up the build process, and generally using fewer resources and significantly reducing the size of the downloadable release assets?

See here:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants