CI: Improve BitBake version mapping for Yocto releases

[rpcme]

Problem

The CI workflow hardcodes the mapping between Yocto release names and BitBake versions in a case statement within .github/workflows/build-test-recipe.yml:

case "${{ needs.changed.outputs.release }}" in
  kirkstone)
    BITBAKE_BRANCH="2.0"
    ;;
  scarthgap)
    BITBAKE_BRANCH="2.8"
    ;;
  whinlatter)
    BITBAKE_BRANCH="2.16"
    ;;
  master)
    BITBAKE_BRANCH="master"
    ;;
esac

This approach has several issues:

1. Maintenance burden: Every new Yocto release requires updating the workflow
2. Error-prone: Easy to forget to update when adding new release branches
3. No single source of truth: The mapping is buried in workflow logic
4. Discovery: New contributors won't know this needs updating

Impact

When a new Yocto release is created (e.g., Wrynose 6.0 in April 2026), the CI will fail with:

fatal: Remote branch wrynose not found in upstream origin

This was discovered when release PRs failed because the workflow tried to checkout non-existent BitBake branches.

Proposed Solutions

Option 1: Configuration File

Create .github/bitbake-versions.json:

{
  "kirkstone": "2.0",
  "scarthgap": "2.8",
  "whinlatter": "2.16",
  "wrynose": "2.18",
  "master": "master"
}

Workflow reads this file and looks up the version.

Option 2: Branch-Specific Configuration

Store BitBake version in each branch's conf/layer.conf or a dedicated file:

BITBAKE_VERSION = "2.8"

Workflow reads from the checked-out branch.

Option 3: Automated Discovery

Query the Yocto Project releases page or use a known mapping table maintained by the community.

Recommendation

Option 1 (configuration file) provides the best balance of:

• Easy to maintain (single file to update)
• Version controlled
• Self-documenting
• Can be validated in CI

References

• Yocto Project Releases: https://wiki.yoctoproject.org/wiki/Releases
• BitBake repository: https://git.openembedded.org/bitbake
• Related fix: commits 67e79b5 (master), d59f60c (master-next), c8c2e57 (kirkstone-next), c2f804f (scarthgap-next), 0b04404 (whinlatter-next)

[rpcme]

Status update (2026-04-09):

Related to #15289. The hardcoded BitBake version mapping is only relevant for master-next and whinlatter-next which use bitbake-setup. The scarthgap-next and kirkstone-next branches clone poky directly (which bundles the correct bitbake version).

No changes to the mapping logic have been made yet. The immediate CI blockers (git:// protocol outage, COMPATIBLE_HOST/MACHINE filtering) have been resolved separately.