asdf-vm/actions

GitHub Actions for the asdf version manager

actions's Issues

Setting up asdf fails

Unclear if I do something wrong: Camelcade/Perl5-IDEA@4ab4947

CI run: https://github.com/Camelcade/Perl5-IDEA/actions/runs/5295899879/jobs/9586664788

Looks like this:

Run asdf-vm/actions/[email protected]
  with:
    asdf_branch: master
    skip_install: false
  env:
    ORG_GRADLE_PROJECT_downloadIdeaSources: false
    CI: GitHub
    GITHUB_TOKEN: ***
    COVERALLS_REPO_TOKEN: ***
    YOUTRACK_TOKEN: ***
    PERL_TEST_VERSION: 5.36.0
    TEST_PERL_MODULES: Mojolicious HURRICUP/Devel-Camelcadedb-v[2](https://github.com/Camelcade/Perl5-IDEA/actions/runs/5295899879/jobs/9586665373#step:5:2)02[3](https://github.com/Camelcade/Perl5-IDEA/actions/runs/5295899879/jobs/9586665373#step:5:3).1.tar.gz Devel::Cover JSON App::Prove::Plugin::PassEnv TAP::Formatter::Camelcade Devel::NYTProf Perl::Tidy Perl::Critic B::Debug Types::Serialiser
    PERL_CONFIGURATORS: LOCAL_ASDF
    JAVA_HOME: /opt/hostedtoolcache/Java_Corretto_jdk/17.0.7.7.1/x6[4](https://github.com/Camelcade/Perl5-IDEA/actions/runs/5295899879/jobs/9586665373#step:5:4)
    JAVA_HOME_17_X[6](https://github.com/Camelcade/Perl5-IDEA/actions/runs/5295899879/jobs/9586665373#step:5:6)4: /opt/hostedtoolcache/Java_Corretto_jdk/1[7](https://github.com/Camelcade/Perl5-IDEA/actions/runs/5295899879/jobs/9586665373#step:5:7).0.7.7.1/x64
Updating asdf in ASDF_DIR "/home/runner/.asdf" on branch "master"
/usr/bin/git remote set-branches origin master
/usr/bin/git fetch --depth 1 origin master
From https://github.com/asdf-vm/asdf
 * branch            master     -> FETCH_HEAD
 * [new branch]      master     -> origin/master
/usr/bin/git checkout -B master origin
fatal: 'origin' is not a commit and a branch 'master' cannot be created from it
Error: Action failed with error Error: The process '/usr/bin/git' failed with exit code 12[8](https://github.com/Camelcade/Perl5-IDEA/actions/runs/5295899879/jobs/9586665373#step:5:8)

Upgrade to Node.js 16

This repository uses Node.js 12 actions, which are deprecated. GitHub Actions recently began adding the following annotation warning all users of asdf-vm/actions:

Node.js 12 actions are deprecated. For more information see: https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/. Please update the following actions to use Node.js 16: asdf-vm/actions

asdf install task fails

4s
Run asdf-vm/actions/install@v2
Cloning asdf into ASDF_DIR "/home/runner/.asdf" on branch "master"
/usr/bin/git clone --depth 1 --branch master --single-branch https://github.com/asdf-vm/asdf.git /home/runner/.asdf
Cloning into '/home/runner/.asdf'...
/home/runner/.asdf/bin/asdf plugin-list
No plugins installed
Installing kustomize plugin...
/home/runner/.asdf/bin/asdf plugin-add kustomize
initializing plugin repository...Cloning into '/home/runner/.asdf/repository'...
Installing kubeval plugin...
/home/runner/.asdf/bin/asdf plugin-add kubeval
Installing conftest plugin...
/home/runner/.asdf/bin/asdf plugin-add conftest
/home/runner/.asdf/bin/asdf install

• Downloading conftest release v0.25.0...
  curl: (22) The requested URL returned error: 404
  asdf-conftest: Could not download https://github.com/open-policy-agent/conftest/releases/download/vv0.25.0/conftest_v0.25.0_Linux_x86_64.tar.gz
  Error: Action failed with error Error: The process '/home/runner/.asdf/bin/asdf' failed with exit code 1

Conftest release is missing.

Install action fails if asdf is already installed

If the correct version is already installed, then I think this action shouldn't fail.

When installing asdf using this action to github action runners, asdf will get installed to a shared directory that isn't wiped and ultimately fails the workflow.

Install asdf step occasionally fails with an error: URL using bad/illegal format or missing URL

.tool-versions:

nodejs 20.4.0
deno 1.29.1
pnpm 8.6.0
terraform 1.4.2
packer 1.8.6
caddy 2.6.4
nomad 1.5.2
vault 1.12.2
jq 1.6
awscli 2.11.1
consul 1.15.4

GH action:

test-job:
  runs-on: ubuntu-latest
  steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0
      - name: Install asdf & tools
        uses: asdf-vm/actions/install@v2

    Error:

After a re-run, it usually passes.

yarn build fails

probably just me (tsc noob), but perhaps worth documenting how to build this repo to encourage contributions
I had to:

npm i @actions/exec
npm i @actions/core
npm i @actions/io
npm i @actions/github
yarn build

yarn add or yarn install was not sufficient to get the bundles to build, and without the npm calls I get a bunch of errors on

yarn build
[...]
 > lib/plugins-add/index.ts: error: Could not resolve "@actions/core" (mark it as external to exclude it from the bundle)
    1 │ import * as core from "@actions/core";
      ╵                       ~~~~~~~~~~~~~~~

.asdfrc not respected

Hello!

I was really excited to see this GitHub Action available, as it could significantly reduce the configuration required to get actions running, but I've run into an issue with using it for nodejs installs.

As you can see in this run, with these configs, the action is ignoring .asdfrc which would allow us to leverage the legacy_version_file = yes configuration and read the nodejs version from .nvmrc.

The project I'm working on has users that would prefer not to force all the developers to switch over to asdf, so the ability to support this would be much appreciated.

Install with `tools` (only allowlisted tools, with versions from `.tool-versions`)

What do we think about the idea of adding support for something like this:

[...]
steps:
  - uses: action/checkout@v4
  - uses: asdf-vm/actions/install@v2
    with:
      tools: |
        action-validator

...so if you have a .tool-versions file like this:

$ cat .tool-versions
action-validator 0.5.3
gcloud 1.2.3

...then it would only asdf install action-validator 0.5.3 (and not gcloud).

My hope is that this could simplify/speed up many jobs where you only need one particular tool for the thing you want to run.

Rewrite without TypeScript compilation

TypeScript compilation and toolchain is adding development overhead, making contributions more difficult. In particular, committing of compiled code is unexpected and confusing for those who have not written GitHub Actions before.

We need to maximise ease of contribution as asdf is a large project and ecosystem.

Typing in JavaScript is still possible using JSDoc - https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html

This method of development has these benefits:

• remove the compilation step
• removes the need to commit compiled code
• reduces the toolchain
• still gives the benefit of typing and editor hinting.

---

As no major efforts are currently being made to improve or develop the asdf-actions further, I would like to steward this project forward with this as a first step.

Thoughts?

Documentation improvements

• About versioning
• About testing in a plain environment

Use Existing Setup Actions When Available

There are already a number of heavily optimized setup actions (e.g., setup-python). Python, for example, can usually be installed at a given recent version more than an order of magnitude faster using the setup-python action than via asdf (when asdf cache misses or always if you aren't using caching). It would be interesting to add a new (default) mode where the official setup actions are used in lieu of the corresponding plugin when possible, which would probably imply a major version bump. There are currently 8 GitHub-authored setup actions, which is where I would propose stopping for the first iteration of this feature. There is a long tail of setup actions authored by other organizations, so I suggest that the asdf community add support for those incrementally in a self-serve fashion if desired. It would be necessary to be able to override the proposed default behavior in case one is testing an asdf plugin itself or requires extremely high fidelity between their development environment and their CI pipeline. Please let me know if anyone has any feedback on such a feature.

Add Contribution guide

This repo should include a contribution guide to demonstrate to others how to set this up

Using plugin-test with asdf-jq

It seems the action plugin-test that asdf-jq uses to test its builds already has jq installed by default, leading to erroneous passing tests

Allow to use a tag instead of a branch in setup

Description

I'd like to setup a job to install an older version of asdf. Right now the setup action takes an asdf_branch variable which limits my ability to use an older version of asdf.

Is it possible to extend this action to allow the use of a specific tag?

How do I add plugins that are not part of the `asdf-plugins` repository?

If I make my own asdf plugin, and I want to reference it in my .tool-version, how do I have the GH Actions know which repository to clone?

Add the ability to install only particular tools

Currently, the install command installs all the tools defined in .tool-versions.
In certain CI workflows, you may need only a subset of the tools. Allow installing only the specified tools.

Are these actions no longer released?

It seems like there have been no releases since 2020 as I see git tags in this repo.
Are these actions no longer released?

Run asdf-vm/actions/install@v1 fail

The following fail messages was copy from logs of GitHub Action 3 days ago:

Run asdf-vm/actions/install@v1
  with:
    asdf_branch: master
  env:
    MYSQL_PASSWORD: password
Cloning asdf into ASDF_DIR: /home/runner/.asdf
/usr/bin/git clone --depth 1 --branch master https://github.com/asdf-vm/asdf.git /home/runner/.asdf
Cloning into '/home/runner/.asdf'...
/home/runner/.asdf/bin/asdf plugin-list
No plugins installed
Installing ruby plugin...
/home/runner/.asdf/bin/asdf plugin-add ruby
initializing plugin repository...Cloning into '/home/runner/.asdf/repository'...
/home/runner/.asdf/bin/asdf install
Downloading ruby-build...
Cloning into '/home/runner/.asdf/plugins/ruby/ruby-build-source'...
Note: switching to 'v20211124'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at 6147a6d ruby-build 20211124
Version not found
Error: Action failed with error Error: The process '/home/runner/.asdf/bin/asdf' failed with exit code 1

And this is the messages from a successful run 5 days ago:

Run asdf-vm/actions/install@v1
  with:
    asdf_branch: master
  env:
    MYSQL_PASSWORD: password
Cloning asdf into ASDF_DIR: /home/runner/.asdf
/usr/bin/git clone --depth 1 --branch master https://github.com/asdf-vm/asdf.git /home/runner/.asdf
Cloning into '/home/runner/.asdf'...
/home/runner/.asdf/bin/asdf plugin-list
No plugins installed
Installing ruby plugin...
/home/runner/.asdf/bin/asdf plugin-add ruby
initializing plugin repository...Cloning into '/home/runner/.asdf/repository'...
/home/runner/.asdf/bin/asdf install
Downloading ruby-build...
Cloning into '/home/runner/.asdf/plugins/ruby/ruby-build-source'...
Note: switching to 'v20211109'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at d796c17 ruby-build 20211109
Downloading ruby-2.3.8.tar.bz2...
-> https://cache.ruby-lang.org/pub/ruby/2.3/ruby-2.3.8.tar.bz2
Installing ruby-2.3.8...

WARNING: ruby-2.3.8 is past its end of life and is now unsupported.
It no longer receives bug fixes or critical security updates.

Installed ruby-2.3.8 to /home/runner/.asdf/installs/ruby/2.3.8

I think the difference between those two cases is the version:

The fail run from 3 days ago:

switching to 'v20211124'

The successful run from 5 days ago:

switching to 'v20211109'

Enable semver major action references eg: `install@v2`

As noted in the docs:

asdf Actions do not currently support referencing by Semantic Version major only. Eg: - uses: asdf-vm/actions/install@v2 is not supported. Work is being done to rectify this.

We should support @v2 as most other GitHub Actions support this despite it being a terrible idea rewriting Git Tags behind peoples backs.

This is a particularly annoying practice since the whole point of asdf is to use the same tools across workflows (local dev vs CI) and developers, but if the action changes underneath people then it is technically not repeatable in the same manner... A truly bizarre decision from the GitHub Actions team for a CICD platform.

Nonetheless, the people will want it... We will recommend against it in the docs with full semver version being preferred. We will leave the note in the docs that people who care about supply chain issues should ref specific commits.

The `set-env` command is deprecated. Please upgrade to using Environment Files.

[bug] MacOS build replaces `version` with literal `https` in download URL

Repository | Failed run

linux

  Switched to branch '7a122abe5c15b92ec5980aa3f9c28f59344367cb'
  redirect url: https://github.com/pypa/pipx/releases/tag/1.2.0
  * Downloading pipx release 1.2.0...
  pipx 1.2.0 installation was successful!
  1.2.0

macos

 Switched to branch '7a122abe5c15b92ec5980aa3f9c28f59344367cb'
  redirect url: https://github.com/pypa/pipx/releases/tag/1.2.0
  * Downloading pipx release https...
  curl: (22) The requested URL returned error: 404
  asdf-pipx: Could not download https://github.com/pypa/pipx/releases/download/https/pipx.pyz
  FAILED: install exited with an error

Why?

Feature request: Caching

It would be very useful if the Github Actions cache system could be integrated with this action. It should be able to save significant time when installing a large list of tools.

Update Node.js

Right now Github Actions warns about old Node.js in this action:

Node.js 12 actions are deprecated. Please update the following actions to use Node.js 16: asdf-vm/actions/setup@v1

I recommend switching to Node.js 18.

set-env being deprecated

Here is the GH Action notice/announcement.

Here is an example of where set-env is being used.

Action authors who are using the toolkit should update the @actions/core package to v1.2.6 or greater to get the updated addPath and exportVariable functions.

The @actions/core package just needs to be updated.

The action doesn't work when we cache the `/home/runner/.asdf` folder with Github Cache action

Hi all, thank you for creating this action.

Problem

We are starting to use this action on our CI workflow; it's working well. The only issue is we can't cache the asdf directory to reduce the installation time.

The installation step takes more than 3 minutes.

We tried to cache that with the Github cache feature by caching the /home/runner/.asdf folder. It ends up with the following error.

Expectation

The action should work with the Github cache. If the asdf or plugins exist in /home/runner/.asdf. Install them directly.

output `.tool-versions` contents as an object

problem

asdf only has *nix support but sometimes we use asdf to build tools for all platforms. When it comes to writting tests for unsupported platforms, namely Windows, we have to resort to doubling up our workflow tool installation.

An example from svelte-adapter-firebase CI pipeline:

      - uses: actions/checkout@v2
      - name: install asdf
        if: matrix.os != 'windows-latest'
        uses: asdf-vm/actions/install@v1
        with:
          before_install: bash -c '${ASDF_DATA_DIR:=$HOME/.asdf}/plugins/nodejs/bin/import-release-team-keyring'

      # START: Windows
      - name: install Node.js on Windows
        if: matrix.os == 'windows-latest'
        uses: actions/setup-node@v2
        with:
          node-version: 14.16.1
      - name: install pnpm on Windows
        if: matrix.os == 'windows-latest'
        run: curl -f https://get.pnpm.io/v6.js | node - add --global pnpm@6
      # END: Windows

      - name: Install svelte-adapter-firebase deps
        run: pnpm install

Note the hardcoded node-version in the Windows section.

solution

If asdf were to output the contents of the .tool-versions file as an object, this could be referenced in later steps in the CI pipeline, removing the need for hard-coded values when supporting other OSs.

EG:

# .tool-versions
nodejs 14.16.1

// asdf action output (asdf_tools)
{
  "nodejs": "14.16.1"
}

# github action
      - uses: actions/checkout@v2
      - name: install asdf
+       id: install_asdf
        if: matrix.os != 'windows-latest'
        uses: asdf-vm/actions/install@v1
        with:
          before_install: bash -c '${ASDF_DATA_DIR:=$HOME/.asdf}/plugins/nodejs/bin/import-release-team-keyring'

      # START: Windows
      - name: install Node.js on Windows
        if: matrix.os == 'windows-latest'
        uses: actions/setup-node@v2
        with:
-         node-version: 14.16.1
+         node-version: steps.install_asdf.outputs.asdf_tools.nodejs

This seems relatively simple to implement and give a more flexible solution to this problem than currently available.

alternatives

I have yet to explore running WSL in the Action Windows runner, which might prove a more useful solution.

An unexecutable error occurs

plugins/deno/bin/install. Must be executable by asdf

New Release

Is it possible to have a new major version release of the actions?

I understand you're following semver, and there are no relevant changes to bump the action versions. But we would like to get rid of deprecation warnings with changes already done in this commit

Thanks in advance

Install action does not honor working-directory

The install action does not appear to honor the working-directory configured in a workflow.

In this repro project I set up, I have a .tool-versions file in the root that configures one version of a tool:
https://github.com/mdobosz-isp/asdf-actions-wrong-dir/blob/d448ef42593a21fef79927bd5e433f2f523b3888/.tool-versions#L1
I also have a subdirectory that sets a different version of the tool:
https://github.com/mdobosz-isp/asdf-actions-wrong-dir/blob/d448ef42593a21fef79927bd5e433f2f523b3888/helm3/.tool-versions#L1

When I execute a workflow that uses the non-default working directory:
https://github.com/mdobosz-isp/asdf-actions-wrong-dir/blob/26d01bec1e7a7b48c5270acce978db41a4e2a3a4/.github/workflows/repro.yml#L22-L34
the action still appears to run in the root working directory, resulting in the wrong version being installed and invocations of the tool failing when the asdf shim tries to load the correct version.

This fails for workflows using the v1.0.0 and master versions of the action.

I would expect that the asdf install command was executed in the appropriate working directory.

The current workaround is to use the plugins-add action (which will also run setup) and run asdf install as a freeform step.

Local git hooks to ensure format and build etc are successful before push

Introduce https://github.com/evilmartians/lefthook to the repo to manage contribution quality local before pushing or raising PRs.

Actions fails to install nodejs lts version

The action fails to install nodejs lts version. I'm not sure if this is just an issue with custom builder, but even if you ssh into the build server, source asdf, install the lts version, then rebuild from github, it still fails with the message:

Cloning node-build...
node-build: definition not found: lts
Error: Action failed with error Error: The process '/home/runner/.asdf/bin/asdf' failed with exit code 1

This does not appear to be a problem with asdf or the nodejs plugin, as it works to install both locally and manually on the server. It only fails through the action.

Add support for configuring asdf inside wsl

Lots of people using Windows runners are running their build code under WSL and it would be very useful to allow asd-vm action setup asdf inside wsl, instead of Windows itself.

feat: CI tooling for asdf plugins which checks for asdf core banned_commands

Provide asdf plugin authors with the ability to utilise the asdf banned commands list in their CI: https://github.com/asdf-vm/asdf/blob/master/test/banned_commands.bats

Allow `asdf-vm/actions/install` (to pass) without `.tool-versions` file

Why does this action fail is there isn't any .tool-versions file?
That's' not how asdf install behaves on my local computer.
There it falls back to check in my home directory for ~/.tool-versions (which this action doesn't seem to do?).
And even then if it isn't there, it doesn't fail, right?

I'd like to use this for a reusable workflow in my organization, where we can "install things from asdf if the repository is using a .tool-versions file, otherwise not".

Today, running this action without a .tool-versions file in the current directory, the action fails with:
Action failed with error Error: ENOENT: no such file or directory, open '.tool-versions'

Set outputs for plugin-test action

As a developer I would like to have the output from the plugin test command to validate my test results as part of the workflow. The improvement to the plugin action could be like:

...
outputs:
  stdout:
    description: "An array of stdout lines the test command"
  stderr:
    description: "An array of stderr of the test command"
  debug:
    description: "An array of debug lines of the test command"

The output essentially are the lines from the exec.exec(...)

plugins-add action does not walk up directory structure to discover all possible plugins

The plugins-add action does not appear to walk up the directory structure to discover all possible plugins to install when a non-default working-directory is configured in a workflow.

In this repro project I set up, I have a .tool-versions file in the root that configures one tool:
https://github.com/mdobosz-isp/asdf-actions-wrong-dir/blob/d448ef42593a21fef79927bd5e433f2f523b3888/.tool-versions#L1
I also have a subdirectory that sets a different tool:
https://github.com/mdobosz-isp/asdf-actions-wrong-dir/blob/d448ef42593a21fef79927bd5e433f2f523b3888/terraform/.tool-versions#L1

When I execute a workflow that uses the non-default working directory:
https://github.com/mdobosz-isp/asdf-actions-wrong-dir/blob/26d01bec1e7a7b48c5270acce978db41a4e2a3a4/.github/workflows/repro.yml#L8-L20
the plugin configured only in the subdirectory does not get installed which makes it impossible to correctly use the install action in that subdirectory (assuming #83 gets resolved) or to run asdf install as a freeform step.

This fails for workflows using the v1.0.0 and master versions of the action.

I would expect that the plugins-add action walked up the directory tree starting from working-directory and assembled the set of plugins to install from all .tool-versions files found.

The current workarounds are:

1. Specify all possible tools and their default versions in the repos root .tool-versions file
2. Run the plugins-add action multiple times for each directory that has a .tool-versions file, however this does not work on the v1 version of the action because #74 has not become part of an official release yet.