There is a caveat to this approach. The action only provides data from GitHub releases. So if someone pushes a Git tag to the repo but doesn't do a GitHub release (which I see happen periodically in Arduino's repositories), then that tag will not be recognized by the action.

So if this approach is used, it will be important to establish a policy of creating a GitHub release for every release of ArduinoCore-API.

If you want tags too, here's an alternative:

      - name: Checkout latest tag of ArduinoCore-API
        run: |
          cd extras/ArduinoCore-API
          git fetch --tags
          git checkout $(git describe --tags $(git rev-list --tags --max-count=1))

Thank you @per1234! I think we can pay attention and adopt this policy. Anyway, if you have other suggestions to work this around, they are more than welcome :)

Thank you for the alternative! If @facchinm @aentinger agree with this second implementation, I proceed.

I personally prefer to do a GitHub release while @facchinm seems to prefer the cli tag approach. If the 2nd implementation covers both approaches (as I understand it) than I suggest you go for it 😉

Because every GitHub release also creates a Git tag, the Git commands I provided in my previous reply will work for both.

The exception is "draft" GitHub releases, which don't create a tag until they are taken out of draft status, but we likely wouldn't want a draft release to be published anyway.

Done! :)