ci(releases): fetch tools versions in its own job

[nikaro]

Fixes: #542

In #496 i introduced a bug in the release process by referencing a not yet defined environment variable env.RELEASE_VERSION in the matrix.
Causing this failure: https://github.com/tamasfe/taplo/actions/runs/7742605055/workflow#L268

This can be fixed by extracting the version fetching steps in its own get_version job and make jobs that require it to depend on it. Then instead of referencing an environment variable we use the get_version job outputs.

I also added the workflow_dispatch trigger to allow running the release workflow manually. So that it should be possible to re-run it to fix the releases, using the desired tag as the git ref:

I've created a dummy repository to test the workflow logic (by fetching and echoing the versions) and it works fine: https://github.com/nikaro/github-actions-testing/actions/workflows/releases-taplo.yaml

• run for the release-taplo-cli-* tags: https://github.com/nikaro/github-actions-testing/actions/runs/7783089054
• run for the vscode extension tag: https://github.com/nikaro/github-actions-testing/actions/runs/7783089031

[JounQin]

Thanks for working this!

[JounQin]

https://github.com/tamasfe/taplo/releases/tag/release-taplo-cli-0.9.1

@nikaro It seems tags are not released automatically anymore?

[JounQin]

Invalid workflow file: .github/workflows/releases.yaml#L268
The workflow is not valid. .github/workflows/releases.yaml (Line: 268, Col: 19): Unrecognized named-value: 'env'. Located at position 1 within expression: env.RELEASE_VERSION .github/workflows/releases.yaml (Line: 270, Col: 19): Unrecognized named-value: 'env'. Located at position 1 within expression: env.RELEASE_VERSION

[nikaro]

@JounQin the changes i did in this PR was to fix this issue specifically. But if you run the workflow with a tag prior to the PR i think that it still use the previous buggy version of the workflow.

You may need create a new one or override the existing one to point to more recent commit (on or after the workflow fix).

[JounQin]

@nikaro So the release must be manual triggered now?

[nikaro]

No, the trigger is still on tags pushes:

on:
  push:
    tags:
      - release-*

[JounQin]

https://github.com/tamasfe/taplo/tags

@nikaro They're not released automatically. (created 3 days ago)

[nikaro]

Ok, i think i understand what's hapenning.

The Continuous integration / Tag Releases did run correctly, pushing new tags: https://github.com/tamasfe/taplo/actions/runs/7920213073/job/21622733377

But since @JounQin is the author here, it looks like the GitHub Personal Access Token of @tamasfe (in secrets.WORKFLOW_PAT) is not accessible. Thus it is empty and/or falls back on the "default" one, GITHUB_TOKEN, which cannot trigger another workflow (cf. doc).

At least that's the only explanation i can think of. Because the Release workflow trigger didn't changed on this part it shouldn't behave differently than before. And i can (sort of) reproduce it:

• default token auto tags pushed -> release workflow not triggered
• use of a custom PAT -> release workflow is run

Did you try to run the workflow manually targeting the tags? In the meantime this could at least let us know if the Release workflow itself is working fine now.

[nikaro]

Or maybe the secrets.WORKFLOW_PAT has been removed, or the PAT it references is expired? Or something like that...

[ia0]

Thanks for the debugging work @nikaro !

@JounQin I guess you're the only one who can check the Settings page of the repository to check if the secrets are present. Otherwise, it's probably simpler to let @tamasfe push the release (once prepared). What do you think?

[JounQin]

I don't have the permission to check the Settings page. 🤣

Organization is much flexible for permission model.

[ia0]

Ah ok :D that solves it then. I think it's better if @tamasfe does the releases then, although we can still prepare them to minimize work.