Skip to content

ci: force build of new/updates recipes #797

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

ndechesne
Copy link
Contributor

In a PR test build, it's possible to have a new recipe (or updates with a bbappend) which is not included in any image we build. We could do a 'world' build but that would be really expensive. Instead this change tries to catch any updated .bb or .bbappend file, and force a bitbake build.

If the recipe was already built as part of the image, it should be a quick no-op. If the recipe was not built, then it's a good thing to check that it builds!

lumag
lumag previously approved these changes Mar 13, 2025
@ndechesne
Copy link
Contributor Author

wait wait.. this needs more testing/thoughts before we merge! e.g. if we try to build linux-qcom-staging (assuming a PR changes that file), we get:

ERROR: Nothing PROVIDES 'linux-qcom-staging'
linux-qcom-staging was skipped: PREFERRED_PROVIDER_virtual/kernel set to linux-yocto-dev, not linux-qcom-staging

Copy link

github-actions bot commented Mar 13, 2025

Test Results

 2 files  ±0   4 suites  ±0   1m 16s ⏱️ ±0s
19 tests ±0  19 ✅ ±0  0 💤 ±0  0 ❌ ±0 
38 runs  ±0  38 ✅ ±0  0 💤 ±0  0 ❌ ±0 

Results for commit c5fd362. ± Comparison against base commit 33a0ecf.

♻️ This comment has been updated with latest results.

Copy link

Test jobs for commit 1985c79

In a PR test build, it's possible to have a new recipe (or updates
with a bbappend) which is not included in any image we build. We could
do a 'world' build but that would be really expensive. Instead this
change tries to catch any updated .bb or .bbappend file, and force a
bitbake build.

If the recipe was already built as part of the image, it should be a
quick no-op. If the recipe was not built, then it's a good thing to
check that it builds!

Signed-off-by: Nicolas Dechesne <[email protected]>
Copy link

Test jobs for commit c5fd362

@ricardosalveti
Copy link
Contributor

wait wait.. this needs more testing/thoughts before we merge! e.g. if we try to build linux-qcom-staging (assuming a PR changes that file), we get:

ERROR: Nothing PROVIDES 'linux-qcom-staging' linux-qcom-staging was skipped: PREFERRED_PROVIDER_virtual/kernel set to linux-yocto-dev, not linux-qcom-staging

Yeah, recipes depending on provides won't work that easily. How is this managed with world?

@ndechesne
Copy link
Contributor Author

How is this managed with world?

world is not a recipe/target. it's intercepted by bitbake and it uses the internal recipe/data store. it would be nice to have a 'world' target that only builds everything from a layer instead.. i am not sure how difficult that would be..

@koenkooi
Copy link
Contributor

wait wait.. this needs more testing/thoughts before we merge! e.g. if we try to build linux-qcom-staging (assuming a PR changes that file), we get:

ERROR: Nothing PROVIDES 'linux-qcom-staging' linux-qcom-staging was skipped: PREFERRED_PROVIDER_virtual/kernel set to linux-yocto-dev, not linux-qcom-staging

If this was purely for populating sstate-cache, I'd suggest using -k, but for actually catching errors, I'm going to suggest filtering out recipes-kernel/linux.

@lumag
Copy link
Collaborator

lumag commented Mar 15, 2025

wait wait.. this needs more testing/thoughts before we merge! e.g. if we try to build linux-qcom-staging (assuming a PR changes that file), we get:
ERROR: Nothing PROVIDES 'linux-qcom-staging' linux-qcom-staging was skipped: PREFERRED_PROVIDER_virtual/kernel set to linux-yocto-dev, not linux-qcom-staging

If this was purely for populating sstate-cache, I'd suggest using -k, but for actually catching errors, I'm going to suggest filtering out recipes-kernel/linux.

Currently we also need to filter boot images and some other packages. If I have time, I will take a look at reworking those recipes to remove possible conflicts.

lumag added a commit that referenced this pull request Mar 28, 2025
Having boot firmware as machine-spefic recipes complicates testing (as
one would have to filter those from CI builds lke #797) and prevents
building rescue images with generic machine configs. Rework boot
firmware, partiion configuration and qcomflash recipes in order to make
that code work with any machine.

Closes #713
Copy link

github-actions bot commented May 1, 2025

This pull request has been marked as stale due to 30 days of inactivity. To prevent automatic closure in 5 days, remove the stale label or add a comment. You can reopen a closed pull request at any time.

@github-actions github-actions bot added the Stale label May 1, 2025
@lumag lumag removed the Stale label May 3, 2025
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.

5 participants