On Tue, 2026-06-02 at 11:59 +0530, Sai Sneha via lists.openembedded.org wrote: > This patch series adds a check for git:// (and other SCM) URIs in > SRC_URI that are missing a corresponding SRCREV, addressing > Bugzilla #16051 [1] and referencing Corentin Guillevic's RFC series [2]. > > == Changes since v4 == > > - Add tag= to skip condition in oe.qa.check_uri_srcrev() alongside > the existing rev= handling. This fixes a selftest breakage > (test_git_unpack_nonetwork) reported by Mathieu Dubois-Briand where > recipes using tag= in SRC_URI intentionally leave SRCREV empty. > - Update docstring to mention tag= parameter > - Verified by running full bbtests.BitbakeTests selftest suite: > 32/33 passed, 1 failure (test_image_manifest) is unrelated as it > requires building a full image and fails due to network constraints > > == Note on CHECKLAYER_REQUIRED_TESTS == > > Paul suggested using CHECKLAYER_REQUIRED_TESTS instead of Patch 4. > We tested this but found it promotes missing-srcrev to ERROR_QA for > ALL layers globally during normal builds, because CHECKLAYER_REQUIRED_TESTS > feeds directly into ERROR_QA. This contradicts Bug 16051 Comment 3 > which requests keeping it as a warning for external layers by default. > The direct implementation in yocto-check-layer.bbclass enforces it > strictly only during checklayer validation without affecting normal builds. > > == Note on candidates list order == > > Martin suggested reversing the candidates list so plain SRCREV is > tested first. We kept most-specific-first order because it mirrors > BitBake internal srcrev_internal_helper() resolution order exactly, > as confirmed by BitBake own error messages: > SRCREV_default:pn-X, SRCREV_default, SRCREV:pn-X, SRCREV > > == Problem == > > A recipe with a git:// URI and no SRCREV causes two problems: > > 1. Under BB_NO_NETWORK=1, parsing fails with a FetchError that halts > parsing of ALL recipes. This breaks CI pipelines that use > bitbake --parse-only as a sanity check. > > 2. Without BB_NO_NETWORK, BitBake silently queries the remote > repository on every parse, breaking reproducibility. > > == Why the trivial fix does not work == > > The obvious fix of checking SRCREV in insane.bbclass do_recipe_qa > was attempted by Corentin Guillevic [2] but fails because > fetcher_hashes_dummyfunc[vardepvalue] expands SRCREV at parse time > BEFORE QA checks run. Corentin patches 1 and 2 add the QA check, > while patches 3 and 4 ensure devtool and recipetool only use > AUTOREV when appropriate. > > == This series approach == > > We intercept at the vardepvalue expansion point in base.bbclass > using a shared helper oe.qa.check_uri_srcrev() that uses > d.getVar(candidate, False) preventing expansion entirely. > > == Design decisions == > > 1. Why not use srcrev_internal_helper() > > It expands SRCREV internally, triggering get_autorev() and live > network fetches. Our fallback chain mirrors BitBake resolution > order exactly without expansion. > > 2. Why duplicate warnings at parse time AND QA time > > Parse-time catches CI parse-only pipelines. QA-time gives proper > layer control. This pattern is established - src-uri-bad does same. > > 3. Why hardcode git/gitsm/hg/svn schemes > > Known limitation, noted as follow-on improvement.
Why don't we do something in the bitbake fetchers which would check if they would need a srcrev lookup and fail if that were the case? We could set something with a layer override which would then trigger any recipe in core to fail to parse if they weren't set deterministically. Looking at the patches, I'm worried we're duplicating fetcher logic in OE-Core and we definitely don't want to be doing that! Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#238074): https://lists.openembedded.org/g/openembedded-core/message/238074 Mute This Topic: https://lists.openembedded.org/mt/119607371/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
