Auto update references for commits, tags, etc

[github-actions]

Automated changes by create-pull-request GitHub action

[gcomneno]

I took a cautious look at the currently open auto-generated maintenance PRs before touching anything, especially because you mentioned an upcoming release.

I did not take any action on these PRs. I’m just flagging what I found, in case it helps with maintainer triage.

#452 — Auto update references for commits, tags, etc

This PR looks suspicious to me and I would not consider it safe as-is.

It is already conflicting, and it only has CodeQL checks, not the main CI/CD workflow.

The most concerning part is the docs update:

• current staging references Yocto 5.2.2 docs
• Auto update references for commits, tags, etc #452 changes scripts/fetch-docs.sh to zeus-22.0.4
• at the same time, other refs move forward, for example Poky moves to yocto-5.2.4

The likely cause seems to be in scripts/update-ref.sh. For yocto-docs, it currently selects the first tag from:

git ls-remote --refs --sort=-v:refname https://git.yoctoproject.org/yocto-docs | head -n 1

That currently selects:

refs/tags/zeus-22.0.4

because 22.0.4 sorts above 6.0 / 5.x, even though the intended docs family appears to be the yocto-* tags.

Filtering to refs/tags/yocto-* would currently select Yocto tags such as:

yocto-6.0_M3
yocto-6.0
yocto-5.3.4
yocto-5.2.4

So #452 appears to expose an overly broad tag-selection rule in the auto-update workflow.

#295 and #460 — Auto update tree-sitter parser info files

These two PRs are mergeable, but they also seem to have only CodeQL checks.

That worries me because the relevant validation for these changes should be the main CI/CD workflow: it runs npm run fetch:wasm, regenerates the WASM parsers from the updated .info files, and then builds/tests the project.

#295 changes server/tree-sitter-bitbake.info from:

idillon-sfl/tree-sitter-bitbake
tree-sitter-cli "^0.22.6"

to:

tree-sitter-grammars/tree-sitter-bitbake
tree-sitter-cli 0.26.9

#460 changes server/tree-sitter-bash.info from:

tree-sitter-cli 0.25.8

to:

tree-sitter-cli 0.26.9

The server runtime is still web-tree-sitter 0.24.7, so I would be cautious about considering parser updates validated by CodeQL alone. The generated WASM parser and the runtime that loads it should be validated together.

I also noticed a small script fragility: scripts/update-tree-sitter.sh writes the CLI version without quotes:

tree-sitter-cli 0.26.9

but scripts/build-tree-sitter-wasm.sh extracts the version as if it were quoted:

sed -n '2p' "$info_file" | cut -d '"' -f 2

With the current bash parser info format, that produces a package spec like:

tree-sitter-cli@tree-sitter-cli 0.25.8

npm 10 tolerates this and resolves the expected version, but it is not a very robust/canonical form to rely on.

Possible next steps

My suggestions, leaving the decision entirely to you:

1. Treat Auto update references for commits, tags, etc #452 as unsafe/stale and either close/regenerate it or fix the tag selection first.
2. Consider filtering the docs refs in update-ref.sh to refs/tags/yocto-*, instead of taking the first version-sorted tag globally.
3. Before merging Auto update tree-sitter-bitbake parser info file #295 or Auto update tree-sitter-bash parser info file #460, trigger the main CI/CD workflow or perform equivalent manual validation of the regenerated WASM parsers against the current web-tree-sitter runtime.
4. Optionally normalize the tree-sitter CLI version parsing so both quoted and unquoted .info formats produce a canonical npm spec such as tree-sitter-cli@0.26.9.

Again, no action taken from my side. I’m just flagging this because these auto-generated PRs look like they need maintainer judgement before being used for release preparation.

[deribaucourt]

Hello @gcomneno, thanks for taking a look!
We are too far behind the current packages versions, similarly, for other dependencies (poky, wasm, ...)
It's more efficient to fix all the failing auto-update PRs manually in one go, fixing all issues. But we'll also need to further bump the major versions in order to keep active support.
I'm currently trying to determine if this is the first thing we should focus on in the backlog with the Yocto Project maintainers themselves. I'm also going to wait for finishing the release process before merging any further updates to avoid any regressions.
For now, let's ignore these.