Open
Conversation
Previously, we had some weird bugs with the CI pipeline sometimes failing (eclipse-basyx#400), but not always reproducible. Namely, sometimes the CI failed, due to `mypy` not finding the `sdk` types when running from the `compliance_tool` environment. Since currently, we are at a point where it is impossible to reproduce the failing CI (at least for me), I decided to clean up the job definitions a little bit and make some things more explicit. Namely, instead of calling scripts like `pip` or `mypy` from their PATH, we now explicitly call them via `python -m pip` and `python -m mypy`. This theoretically ensures, that it always uses the script we just installed with the dependencies and not something the VM already had in its path via `actions/setup-python@v5`. This should ensure that a script like `mypy` actually has all the necessary dependencies installed. Secondly, we had a `pip install -e ../sdk[dev]`, therefore installing the development dependencies of the `sdk` in the `compliance_tool` CI check. This is technically incorrect, since we use the `sdk` as external dependency and therefore shouldn't depend on the development dependencies. I therefore removed this. Lastly, the `sdk-readme-codeblocks` check uses `bash` syntax. In theory, the Ubuntu environment should use `bash` by default, but now it is made explicit. Fixes eclipse-basyx#400 (hopefully)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Previously, we had some weird bugs with the CI pipeline sometimes failing (#400), but not always reproducible. Namely, sometimes the CI failed, due to
mypynot finding thesdktypes when running from thecompliance_toolenvironment. Since currently, we are at a point where it is impossible to reproduce the failing CI (at least for me), I decided to clean up the job definitions a little bit and make some things more explicit.Namely, instead of calling scripts like
pipormypyfrom their PATH, we now explicitly call them viapython -m pipandpython -m mypy. This theoretically ensures, that it always uses the script we just installed with the dependencies and not something the VM already had in its path viaactions/setup-python@v5.This should ensure that a script like
mypyactually has all the necessary dependencies installed.Secondly, we had a
pip install -e ../sdk[dev], therefore installing the development dependencies of thesdkin thecompliance_toolCI check. This is technically incorrect, since we use thesdkas external dependency and therefore shouldn't depend on the development dependencies. I therefore removed this.Lastly, the
sdk-readme-codeblockscheck usesbashsyntax. In theory, the Ubuntu environment should usebashby default, but now it is made explicit.Fixes #400 (hopefully)
Note
After closing this PR we should immediatly merge this back to
developas well.