ci: yocto-check-layer: set BSP machines to be tested #80
Conversation
This file contains 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
ndechesne
requested review from
quaresmajose,
ricardosalveti and
sbanerjee-quic
as code owners
ndechesne
force-pushed
the
checklayer
branch
2 times, most recently
from
4bbf95b to
ae6e42a
Compare
ndechesne
force-pushed
the
checklayer
branch
from
ae6e42a to
cb4c2de
Compare
ndechesne
force-pushed
the
checklayer
branch
from
cb4c2de to
d54963c
Compare
When running yocto-check-layer, we can see the following logs:
INFO: test_machine_signatures (bsp.BSPCheckLayer)
INFO: ... skipped 'No machines set with --machines.'
INFO: No machines set with --machines.
INFO: test_machine_world (bsp.BSPCheckLayer)
INFO: ... skipped 'No machines set with --machines.'
INFO: No machines set with --machines.
Because we do not set --machines when running the script, it does not
try to run the tests with each individual machine. When setting
machines, yocto-check-layer will ensure that all signatures do not
change when setting MACHINE for each our supported machine. So we can
catch more errors. Note that this is also what would be done by Yocto
if we wanted to run the compliance tests.
E.g. from Yocto docs:
bsp.test_machine_world: Verifies that bitbake world works regardless
of which machine is selected.
bsp.test_machine_signatures: Verifies that building for a particular
machine affects only the signature of
tasks specific to that machine.
Signed-off-by: Nicolas Dechesne <[email protected]>
In the Github actions for yocto-check-layer, we can see the following
error:
INFO: Traceback (most recent call last):
File "/opt/actions-runner/_work/meta-qcom-hwe/meta-qcom-hwe/poky/scripts/lib/checklayer/cases/common.py", line 87, in test_patches_upstream_status
self.assertEqual(len(patches), 0 , \
AssertionError: 1 != 0 : Found following patches with malformed or missing upstream status:
/opt/actions-runner/_work/meta-qcom-hwe/meta-qcom-hwe/poky/meta/lib/oeqa/manual/abat.patch
Since KAS_WORK_DIR is not set, and since kas is executed from inside
the repo, we end up cloning poky and meta-qcom inside meta-qcom-hwe
repo. As such yocto-check-layer will 'parse' the entire poky (and
meta-qcom) repo , especially when looking for .patch files. Arguably
yocto-check-layer could be smarter and skip .patch files not
referenced in a valid recipe.. but it's not the case.
So we need to ensure that we checkout the kas workspace outside of our
repo. With this patch we either let the caller manage KAS_WORK_DIR, or
we create a temporary directory ourselves (typically in Github Actions).
This patch fixes the error mentioned above.
Signed-off-by: Nicolas Dechesne <[email protected]>
ndechesne
force-pushed
the
checklayer
branch
from
d54963c to
d2c1d57
Compare
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
|
we need to set the KAS_WORK_DIR and create it on the github action job |
We can indeed, but it's not strictly needed. especially for yocto-check-layer and yocto-patchreview, we don't build anything, so using the temp folder in /tmp is ok, it is thrown away when the job is done anyway. So can we merge this PR (and the one about patchreview) first, and then we can decide if we want to set KAS_WORK_DIR globally for all jobs in build-yocto workflow? does that work for you? |
|
Another thing I see we are not using here is the KAS_REPO_REF_DIR which already contains the repositories. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
When running yocto-check-layer, we can see the following logs:
INFO: test_machine_signatures (bsp.BSPCheckLayer)
INFO: ... skipped 'No machines set with --machines.'
INFO: No machines set with --machines.
INFO: test_machine_world (bsp.BSPCheckLayer)
INFO: ... skipped 'No machines set with --machines.'
INFO: No machines set with --machines.
Because we do not set --machines when running the script, it does not try to run the tests with each individual machine. When setting machines, yocto-check-layer will ensure that all signatures do not change when setting MACHINE for each our supported machine. So we can catch more errors. Note that this is also what would be done by Yocto if we wanted to run the compliance tests.
E.g. from Yocto docs:
bsp.test_machine_world: Verifies that bitbake world works regardless
of which machine is selected.
bsp.test_machine_signatures: Verifies that building for a particular
machine affects only the signature of
tasks specific to that machine.