Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make setup-tools runnable locally #1263

Open
blampe opened this issue Jan 3, 2025 · 0 comments
Open

Make setup-tools runnable locally #1263

blampe opened this issue Jan 3, 2025 · 0 comments
Labels
kind/enhancement Improvements or new features

Comments

@blampe
Copy link
Contributor

blampe commented Jan 3, 2025

It can be very difficult if not impossible to get a local environment to look the same as the environment we use in CI, with all of the relevant toolchains and dependencies installed at the correct versions.

This can make it really difficult to debug issues in CI, especially if the problem boils down to something like changes in a language toolchain's version.

Ideally, developers and CI should be able to share the same setup steps.

Proposal

As a starting point, I'll suggest we experiment with something like mise:

This is similar to asdf with nicer support for Go tooling -- helpful considering all of the small programs we use as part of our workflows. Unlike nix, dev containers, etc. it doesn't require Docker/sudo so it's usable locally, as well as on CI and in other places like our Renovate worker.

As part of setup-tools we can check if a project has a .mise.toml defined (example -- here the operator specifies the protoc version it needs), and if it does use that to setup all the tools:

- name: Run mise
  if: ${{ hashFiles('.mise.toml') != '' }}
  uses: jdx/mise-action@v2
  with:
    ...

Other benefits:

  • This caches all of our tools, which speeds up setup and preserves things like previously downloaded packages.
  • Renovate can natively manage .mise.toml, so the problem of toolchain upgrades -- currently handled via action versions in ci-mgmt -- can instead be handled (more appropriately) by the provider itself. This would, for example, reduce our maintenance burden from long-tail providers: it would be possible to allow a provider to stay on older versions of Go, or golangci-lint, etc., for example, instead of forcing someone to manually resolve incompatibilities across all of our providers whenever we want to upgrade something.
@pulumi-bot pulumi-bot added the needs-triage Needs attention from the triage team label Jan 3, 2025
@iwahbe iwahbe added kind/enhancement Improvements or new features and removed needs-triage Needs attention from the triage team labels Jan 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement Improvements or new features
Projects
None yet
Development

No branches or pull requests

3 participants