Conflict with cracklib-dicts packer on self-hosted runners

[mrmeyers99]

Expected Behavior

      - name: Setup `packer`
        uses: hashicorp/setup-packer@v2.0.0
        with:
          version: "1.8.4"

      - name: Build AMI
        run: packer --version

This should print out 1.8.4, indicating that I'm using the packer binary that the Github Action just installed

Current Behavior

It actually prints out 0 0. This is because it's actually using /usr/sbin/packer which is installed by cracklib-dicts on amazon linux.

Steps to Reproduce

Run the above code on a self hosted runner which uses Amazon Linux

Potential Solutions

The two solutions I can think to solve this are: 1) Add the directory which contains the downloaded packer to the beginning of the PATH. Not sure if this is possible. 2) Add an otuput variable which contains the absolute path of the packer command which was just downloaded. Then I can use that instead of just using packer

[ksatirli]

Thanks for reporting this @mrmeyers99!

This is an interesting use-case and one we don't currently support (as you noticed). While I cannot commit to fixing this right now, I'll think this through some more.

Maintainers: I believe we'd want to fix this in setup-binary.ts in github-actions-core. Doing so would make this available to all GHAs down the road.

[ksatirli]

Digging into this some more @mrmeyers99;

I came across https://github.com/cracklib/cracklib/issues/7#issuecomment-468183528 - which indicates that this seems to be a known problem.

The best and immediate fix right now would be to use unlink to unlink the cracklib version of packer using unlink /usr/sbin/packer.

I believe in an Action, you could use this like so:

  steps:
    # unlink `cracklib` version of `packer`, see https://github.com/cracklib/cracklib/issues/7#issuecomment-468183528
    - run: unlink /usr/sbin/packer

    # other Action Steps go here
    ...

Let me know if this works!

[EDIT]

Previously discussed in /hashicorp here: https://github.com/hashicorp/packer/issues/6191

[mrmeyers99]

Thanks, that would be ok as a workaround, but it would be nice to not have to do that.

[ksatirli]

Marking this as wontfix as we have no control over other project's binary names.