Yocto AUTOREV: Understand When a Moving Revision Enters Task Metadata

A recipe still says SRCREV = "${AUTOREV}", but today's build uses a different commit from yesterday's. That is expected behavior for a moving source selection, not evidence that the recipe file changed. A second surprise is that resolving the source can require network access before a visible do_fetch task starts.

For a Yocto embedded Linux development branch, automatic revision tracking can be useful. Release preparation requires identifying the resolved commit and understanding how it enters both build metadata and package versions. The references here cover Yocto 5.0.12, BitBake 2.8, and the corresponding upstream maintenance-branch source read during preparation.

Separate the moving request from its resolved answer

The AUTOREV reference defines the request to use the repository's latest source revision. The repository URL, selected branch, and overrides still determine which moving reference is being followed. A default branch assumption can therefore select a different history than intended.

Inspect the effective source metadata for the selected recipe, then identify the full resolved revision used by that build. Preserve that revision alongside the repository identity. Recording only the literal AUTOREV assignment cannot distinguish two builds that resolve it at different times.

Do not infer the selected commit from the current remote branch tip after the build has finished. The branch may have advanced again. Inspect the build's source-resolution evidence and checked-out source, while accounting for any subsequent local modifications.

Why metadata processing can contact the repository

In the BitBake fetch implementation, automatic revision handling marks recipes as noncacheable unless the source-revision cache policy is selected. Revision lookup also has a cache path. These details mean “latest” is mediated by the configured policy, rather than being a fresh remote query at every individual use.

The Git fetcher implementation resolves an unresolved reference through remote-reference lookup when needed. The OpenEmbedded base class includes resolved source hashes in fetch-task dependency metadata. Resolution can therefore arise while metadata and signatures are being prepared, before the download task is executed.

If an offline invocation fails during expansion or parsing, inspect the complete error chain for revision resolution. Having a cached source checkout does not necessarily answer which commit an upstream moving branch currently names. Diagnose that selection requirement instead of assuming every network error must originate in a running fetch task.

The maintenance branches can receive backports. Compare these functions with the exact checkout used by the product when debugging timing or caching details.

Package identity is a second mechanism

The automatic package-version guide requires a plus sign in PV, such as PV = "1.0+git", to incorporate source-control information into PKGV in this documented release. Inspect the generated package version rather than assuming the source assignment alone guarantees a useful identifier.

The same guide explains the AUTOINC contribution: without a PR service, its replacement is zero, so changed source hashes do not produce a guaranteed linearly increasing package-version sequence. A package manager's upgrade ordering is therefore separate from BitBake noticing changed source inputs.

Keep feed-version policy outside the source-selection shortcut. An automatic development build can correctly compile a new commit while producing a package-version ordering unsuitable for the intended upgrade path.

Freeze the selection without confusing it with source availability

For a release candidate, replace the moving selection with the reviewed full revision in the appropriate metadata and confirm the effective value. Check every named repository input if the recipe fetches more than one. A pinned primary repository does not freeze an independently floating secondary source.

Then confirm that the pinned revision's source objects are available through the supported fetch path. Pinning answers which source is intended; source retention answers whether it can be retrieved later. Neither follows automatically from a successful earlier development build.

The essential distinction is between the moving request, its resolved commit, the task-input identity, and the package version delivered to an updater. Inspecting all four explains changes that an unchanged recipe filename cannot.