actions: Create workflow to update shell tools via auto-PR

[ColorfulRhino]

Description

I'm sorry, I have created a monster 🧌
But this happens when you create a monster by embedding dependency versions inside shell script files 😅

This workflow is carefully crafted though and works surprisingly well imo :)

---

Some of our scripts download tools from a repo. These can't be bumped by dependabot, so this workflow is a self-created dependabot to bump versions of those tools to stay up-to-date. This workflow only creates a PR if the version was actually updated.

Tools currently supported:

• Shellcheck (in 2 different files)
• Shellfmt
• oci-oras
• Bat

This will only run once a month since the tools we use are usually not updated frequently. Maybe every two weeks/twice a month would also be fine? Let me know.

How Has This Been Tested?

• Workflow run: https://github.com/ColorfulRhino/build/actions/runs/9857502042
• Created PR: Bump oras-project/oras from 0.16.0 to 1.2.0 in lib/functions/general/oci-oras.sh ColorfulRhino/build#8

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• Any dependent changes have been merged and published in downstream modules

[rpardini]

Very interesting and useful.
In general we can bump those tools versions at will.
Except I'd say for oras -- specially a bump from a 0. major to a 1. major will bring breaking changes.
So maybe detect if major is changing and add an extra warning to the PR.

We might even take this further in the future and bump things like kernel -rc's, etc...

[ColorfulRhino]

So maybe detect if major is changing and add an extra warning to the PR.

Yes, this can be added as well as a comparison if the version from the latest tag is actually higher (sometimes latest doesn't mean newest), there's a tool to compare semvers. I don't have plans to implement this soon though.

Like any PR this auto-PR should be reviewed and in case of things like ORAS tested if it does not break anything of course 😄

We might even take this further in the future and bump things like kernel -rc's, etc...

This should be possible with some workarounds since kernel is hosted also on GitHub (including RC tags), but doesn't have a latest tag for example. So probably that would be a different workflow file if I'm thinking about it 😅

[rpardini]

and in case of things like ORAS tested if it does not break anything of course

ORAS bump is special in this case. Not only ORAS, but the OCI spec itself has changed. Testing is complex, because there's two moments where ORAS is involved:

1. When uploading an artifact. The ORAS version determines details about the manifest, etc. Usually always works -- or seems to
2. When download an artifact. Depending on wth ORAS version put the manifest there this might fail, eg old manifest vs new version, and old version vs new manifest.

I tried to bump to ORAS 1.2.y (since that brings a prebuilt riscv64 bin, and I wanted to enable folks to build on riscv64, not only for riscv64) and faced those challenges, only realizing after a while it was the combo of 1 and 2 above that caused troubles.

So a coordinated "change ORAS and force a rebuild/reupload of all artifacts" might be needed.

---

Either way this is unrelated to this PR, which is about sending us automated PR to bump versions.

I'd say merge, lets try it out -- it might become a nuisance, eg, "we can't bump ORAS, stop sending us PR's!" but fix-it-when-it-see-it-actually-happening?

[ColorfulRhino]

ORAS bump is special in this case. Not only ORAS, but the OCI spec itself has changed. Testing is complex, because there's two moments where ORAS is involved:

Ah, interesting! I assume this is only the case because the switch would be from 0.x to 1.x? According to semver specs, only major versions can introduce breaking functionalities.

So a coordinated "change ORAS and force a rebuild/reupload of all artifacts" might be needed.

This is probably doable if we don't need to do this every few weeks I guess 😄
But that's a thing for the PR that will inevitably get auto-created by the bot.

[igorpecovnik]

BTW.

Doku for actions - in case needed:
https://docs.armbian.com/Process_CI/

Incoming updates:
armbian/documentation#449