-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Update build workflow #1608
Conversation
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]>
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 |
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. |
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? |
I'll do some more tests and then update the night release script as well to also do caching etc... |
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]>
I see the only controversial point has gone - the ubuntu version stuffs, so I am happy to moving this forward :) |
@mickflemm thank you!!! |
Thanks @kito-cheng ! |
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 See here: |
This series aims to improve the current build workflow as suggested in #1591.