Skip to content

Conversation

@per1234
Copy link
Contributor

@per1234 per1234 commented Sep 16, 2025

The "yq" tool is used by the poetry:install task.

Previously, the tool was not managed in any way.

The GitHub Actions workflows used whichever version of yq happened to be installed on the runner machine. This meant that the GitHub Actions workflows could break at any time through the "yq" installation on the runner machine being updated to an incompatible version.

And the task would fail entirely if executed on a Windows runner (as is done by the "Test Integration" workflow) due GitHub not providing an installation of "yq" on that runner.

The contributors used whichever version of "yq" happened to be installed on their machine. This meant that they might get different results from that produced by the environment of the GitHub Actions workflows. If they didn't already have an installation, they would need to manually install the dependency.

The better solution is to take the same approach for managing the "yq" dependency as is done for the project's other dependencies:

  • Install a specific version of "yq" according to a single source of versioning data.
  • Use the Dependabot service to get automated update pull requests.

The "yq" tool is used by the `poetry:install` task.

Previously, the tool was not managed in any way.

The GitHub Actions workflows used whichever version of yq happened to be installed on the runner machine. This meant
that the GitHub Actions workflows could break at any time through the "yq" installation on the runner machine being
updated to an incompatible version.

And the task would fail entirely if executed on a Windows runner (as is done by the "Test Integration" workflow) due
GitHub not providing an installation of "yq" on that runner.

The contributors used whichever version of "yq" happened to be installed on their machine. This meant that they might
get different results from that produced by the environment of the GitHub Actions workflows. If they didn't already have
an installation, they would need to manually install the dependency.

The better solution is to take the same approach for managing the "yq" dependency as is done for the project's other
dependencies:

* Install a specific version of "yq" according to a single source of versioning data.
* Use the Dependabot service to get automated update pull requests.
@per1234 per1234 self-assigned this Sep 16, 2025
@per1234 per1234 added type: enhancement Proposed improvement topic: code Related to content of the project itself labels Sep 16, 2025
@per1234 per1234 merged commit ea2c82a into arduino:main Sep 16, 2025
51 checks passed
@per1234 per1234 deleted the manage-yq branch September 16, 2025 04:06
@per1234
Copy link
Contributor Author

per1234 commented Nov 3, 2025

Use the Dependabot service to get automated update pull requests.

I discovered that I was mistaken about this effect. Although Dependabot does provide update PRs when tool dependencies are managed via the alternative provisional "tools.go" approach, unfortunately it does not for tools managed via the newer tools directive: dependabot/dependabot-core#12050

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

topic: code Related to content of the project itself type: enhancement Proposed improvement

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant