Release: ff-merge master-next → master (2026-W30) - #16434
Merged
Conversation
The yocto-check-layer workflow was using Yocto release codenames directly as BitBake branch names (e.g. -b wrynose), but BitBake uses version numbers for branches (2.8, 2.16, 2.18, etc). This caused all wrynose-next PR checks to fail with: fatal: Remote branch wrynose not found in upstream origin Add explicit mapping: scarthgap -> 2.8 whinlatter -> 2.16 wrynose -> 2.18 master -> master Also add retry logic for git clone (matching build-test-recipe.yml) since git.openembedded.org has intermittent availability issues.
Replace korthout/backport-action (which used git cherry-pick and produced draft PRs with unresolvable merge conflicts) with the backporter tool from meta-aws-ci. The new approach performs clean version upgrades on each target branch: - git mv to new version filename - Update SRCREV or sha256sum hashes - Gracefully skip if recipe doesn't exist or is already at version Adds workflow_dispatch support for manual testing with explicit inputs: recipe, version, srcrev/sha256sums, target_branches Triggered automatically on PR merge to master-next (same as before) when labeled 'version-upgrade' or 'auto-backport'.
The -f flag forces rebuild of the entire dependency tree, causing recipes with heavy deps (fleetwise: boost, protobuf, abseil, aws-sdk-cpp) to exceed the 4-hour CI timeout. Use cleansstate on just the changed recipes instead, allowing dependencies to be served from sstate cache while still ensuring the target recipes are rebuilt from scratch.
Remove both `-c cleansstate` (added in previous commit) and `-f` (original). cleansstate on shared EFS sstate-cache causes: - Cross-job sstate invalidation (concurrent builds stomp each other) - Hash equivalence server overload (SQLite write contention on NFS) - False-positive build failures from hashserv timeout warnings The -f flag forces rebuilds of the entire dependency tree, causing 4-hour CI timeouts for recipes with heavy deps. Neither is needed: when the auto-upgrader changes a recipe's SRCREV or version, the task hash changes naturally and bitbake will rebuild from source. Dependencies are served from sstate as expected.
Each Yocto release now gets its own hashserv instance: - hashserv-master.internal:8686 - hashserv-scarthgap.internal:8686 - hashserv-whinlatter.internal:8686 - hashserv-wrynose.internal:8686 Endpoints are configured via GitHub Actions repository variables (HASHSERV_master, HASHSERV_scarthgap, etc.) so new releases can be added without code changes. This eliminates cross-release hash contamination and reduces load on any single hashserv instance under concurrent builds.
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
3 participants
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.
Weekly Release — Fast-Forward Merge
Merges all changes from
master-nextintomasterfor the week 30 release.Key changes since last release (2026.26.0, Jun 23):
Release criteria:
master-2026.30.0