Fix broken CI #586
Fix broken CI #586
Conversation
|
The 2nd commit looks fine but it is a library code fix so I don't think it should come in the same PR as "Fix CI". (This is visible in the release notes if you use the github release note creation help) The big problem with the CI files is it uses ubuntu:latest in the Dockerfile and thus we are at the whim of Ubuntu (LTS) releases. I did verify that we are getting 24.04 right now. I suggest you change ubuntu:latest to ubuntu:22.04 for now. Or if you prefer we can do 24.04 but we should be in control. I never liked the env handling in this setup as it is split between the Dockerfile and the entrypoint.sh. A clean 24.04 container has nothing in /etc/timezone and /etc/localtime so I will need to figure what new thing is happening and why. I would change: I don't think --break-system-packages should be needed if you use --user. I would suggest we use --user for them all instead of mixing them as they now are. (Update: FALSE, still needed) I will try these out and let you know. |
|
Unfortunately even --user requires the --break-system-packages at least at the moment. Some people think (as I do ) that it should not be needed by --user. The argument that --user can break distro packages is very week to me as they are only in the path for interactive shells. You have to explicitly opt into them otherwise. Anything in /usr/local is far worse than something in ~/.local/bin. |
|
@arnopo I have tested this with github actions and with desktop testing. If you agree I will do the same for libmetal. If you agree, do you want a new PR or do you want me to force push to this one after you separate the lib code fix? |
|
System packages can still be "broken" by user installs from the user perspective. Even though the overridden packages only apply in interactive shells, you still don't want to break your user shell with mismatched packages either. If we need specific packages, the recommendation is For now, cleanest approach is just lock to 22.04, so +1 for that. |
|
@wmamills |
I keep it in this PR to have the CI pass. I will remove it before merging. |
|
If you create a venv then all the stuff to handle ~/.local/bin is really not needed. Yes, once your are in an activated venv it knows which python version you want and you can use pip instead of pip3 but I am not sure everyone will understand why that is safe now. Which approach we use here in this contained environment is not really important but the command lines look cleaner now. I do agree using a venv whenever you have a -r file is a good idea. I strongly disagree that --user is always bad. |
.github/actions/build_ci/Dockerfile
Outdated
|
|
||
| ENV LANG C.UTF-8 | ||
| ENV LC_ALL C.UTF-8 | ||
|
|
||
| # If this dir exists, then global bashrc scripts will take care of adding it to the path |
There was a problem hiding this comment.
This section is no longer needed
| ln -s /usr/share/zoneinfo/Etc/UTC /etc/localtime || exit 1 | ||
| ln -fs /usr/share/zoneinfo/Etc/UTC /etc/localtime || exit 1 | ||
|
|
||
| # use ~/.local/bin even for non-interactive shells |
There was a problem hiding this comment.
This section is no longer needed
arnopo
force-pushed
the
fix_CI
branch
2 times, most recently
from
d74e169
to
4cab6af
Compare
|
I replaced pip by pip3 |
|
Update CI to work with 24.04.
* Lock to 24.04 so we control when to change
* Update locale and timezone to work for 24.04 or 22.04
* 24.04 creates these files if not already there but 22.04 does not
* Keep existing work around for 22.04 but make it work if already there
* use venv
* Breate a virtual environment isolated from the packages in the base
environment
* Inspired from zephyr build environment
* Use pip3 everywhere removing global and --user installation
* Add section to README about desktop testing
* Also fix usage formatting in README
Co-developed-by: Bill Mills <bill.mills@linaro.org>
Signed-off-by: Bill Mills <bill.mills@linaro.org>
Co-developed-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
The "open-amp lib Continuous Integration / check builds on different platforms" check has failed due to a Docker environment update.
Issues were found related to timezone settings and pip3. Upon fixing these, a build error was reported by GCC (likely a new version) in rpmsg_rpc_client.c.
This PR addresses both issues to restore a working CI environment.