chore(ci): replace mbta/actions/reshim-asdf

[rwaskiewicz]

Asana task: N/A

Description
Replace mbta/actions/reshim-asdf with bash equivalent commands. In
the v2.20 release, commit mbta/actions@3579cb7
marked the reshim-asdf action as deprecated. A recent Dependabot update
attempted to bump this action's version to v2.21 - while the update
would succeed otherwise, replace the action now while it's on top of
mind.

(Note: Since we're using tags instead of SHAs for this action, we're technically already using v2.20 (v2 still points at one minor behind as of this writing) in its deprecated state)

The existing job structure of the CI workflow has been maintained as-is.
In the future, there is room to refactor this to either a composite
action or series of parallel steps, which would eliminate the need to
pass the ASDF_DIR and ASDF_DATA_DIR values between jobs. However,
since this is an unplanned task created to avoid a deprecated Action,
leave that for another day.

asdf-vm/actions/setup was not used here. While the action can achieve
the same effect as the new asdf_env_setup step, it did not seem worth
it to have to manage an additional dependency for setting up something
on our PATH. In the future, when Dependabot PRs are grouped and/or the
CI workflow is refactored, this can certainly be re-explored (i.e. this
is a judgment call more than anything).

• For features with a design/UX component, deployed branch to dev-green and let product know it's ready for review.

[digitalcora]

asdf-vm/actions/setup was not used here. While the action can achieve the same effect as the new asdf_env_setup step, it did not seem worth it to have to manage an additional dependency for setting up something on our PATH. In the future, when Dependabot PRs are grouped and/or the CI workflow is refactored, this can certainly be re-explored (i.e. this is a judgment call more than anything).

Mm, I don't love this, for a few reasons:

• Introduces more complexity/hand-rolled code for a situation where a supported "library" already exists
• We are already using setup in Screens, so this is introducing a third way of doing ASDF setup among our projects, instead of using one of the two existing ways
• "the future" could very easily be now — the change to group Actions updates for Dependabot would be tiny, and in that case the overhead of keeping the additional dependency up-to-date becomes also tiny

Does this sway your judgment? 😄

[rwaskiewicz]

asdf-vm/actions/setup was not used here. While the action can achieve the same effect as the new asdf_env_setup step, it did not seem worth it to have to manage an additional dependency for setting up something on our PATH. In the future, when Dependabot PRs are grouped and/or the CI workflow is refactored, this can certainly be re-explored (i.e. this is a judgment call more than anything).

Mm, I don't love this, for a few reasons:

* Introduces more complexity/hand-rolled code for a situation where a supported "library" already exists

* We are already using `setup` [in Screens](https://github.com/mbta/screens/blob/main/.github/actions/setup/action.yml), so this is introducing a third way of doing ASDF setup among our projects, instead of using one of the two existing ways

* "the future" could very easily be now — the change to group Actions updates for Dependabot would be tiny, and in that case the overhead of keeping the additional dependency up-to-date becomes also tiny

Does this sway your judgment? 😄

Kinda, but I'm still on the fence 😅

I'd argue that the complexity here is low as far as the bash goes. In fact, we do more-or-less the same thing on signs-ui - not that writing the same bash in more than one place is going to make anyone like it more 😆

I have a slight inclination to not using the setup action as the asdf and build jobs exist today, mostly because:

• We don't see reap the benefits of setup handling OS-specific directory handling for us
• I didn't love that I had to read the TypeScript source to understand how setup behaved; specifically I have bias against abstractions that aren't well documented. But, I'll concede maybe I'm not well-versed enough in this ecosystem for the documentation as-is to "just make sense".

I had considered switching over to a composite action here and using setup similar to how we do on Screens, but that felt like a step too far in terms of the immediate goal (get us off the MBTA-specific action).

I'll spend my "Dependabot review time" (catchier name TBD) tomorrow AM, and see what this looks like with setup

[digitalcora]

I had considered switching over to a composite action here and using setup similar to how we do on Screens

In my mind these two things are not connected; we could use asdf-vm/actions/setup here without introducing a composite action system like in Screens. I perhaps didn't distinguish well enough in my comment between setup (the name of the composite action Screens has implemented) and setup (the name of the reusable workflow provided by asdf-vm, which the Screens composite action of the same name also uses).

[rwaskiewicz]

@digitalcora

In my mind these two things are not connected; we could use asdf-vm/actions/setup here without introducing a composite action system like in Screens. I perhaps didn't distinguish well enough in my comment between setup (the name of the composite action Screens has implemented) and setup (the name of the reusable workflow provided by asdf-vm, which the Screens composite action of the same name also uses).

To be fair, I probably didn't distinguish between the two well either. I think we were both talking about asdf-vm/actions/setup for a good part of the conversation - at least that's what I had assumed and is the context behind reasoning for not wanting to use the asdf-vm setup action.

That all said, I've updated this PR to use asfd's setup action - I'm not so biased against this action to not give it a go.