feat: Set JULIAUP_DEPOT_PATH to a location in the runner tool cache

[krynju]

Found because a worker had juliaup preinstalled and we've hit Error: The Julia launcher failed to figure out which juliaup channel to use.

I think it makes more sense to put it in the runner cache, so that it completely ignores what's currently on the runner.

[DilumAluthge]

Would you be able to put the changes that touch lib/* and dist/* into a separate commit? It makes review a little easier, and also it makes it easier when rebasing and fixing merge conflicts.

[DilumAluthge]

At first glance, at a high-level, this seems reasonable to me, but I haven't done a line-by-line review yet.

[krynju]

Would you be able to put the changes that touch lib/* and dist/* into a separate commit? It makes review a little easier, and also it makes it easier when rebasing and fixing merge conflicts.

Done

[DilumAluthge]

I left one comment, but overall this makes sense and we should do it.

Users can recover the old behavior by manually setting the JULIAUP_DEPOT_PATH environment variable themselves.

One question though, is whether this is breaking. My initial instinct is that it is breaking. @MichaelHatherly what do you think?

We could work around it by making it opt-in in the current major version of install-juliaup, which would be nonbreaking. And then we could change the default in a future major release.

[MichaelHatherly]

My initial instinct is that it is breaking.

I'm inclined to agree with that. Opt-in during this current major release and then switching it in the next might be the most reasonable.

[krynju]

My initial instinct is that it is breaking.

I'm inclined to agree with that. Opt-in during this current major release and then switching it in the next might be the most reasonable.

Assuming people use the action as intended it shouldn't be breaking. The only side effect I think would be that the cache is not reused on next the first run after the upgrade.
But I'm not 100% sure people use it as intended

[DilumAluthge]

I've been giving this some more thought, and I wonder if we can call this a bugfix, with the idea being that GitHub Actions are expected to use the toolcache generally, so the fact that we haven't been using the toolcache up until now could be considered a bug. So then we'd say this is a bugfix, but users that need to recover the old behavior can manually set the JULIAUP_DEPOT_PATH environment variable prior to running this action. Users shouldn't actually experience any breakage, it's just that they'll need to redownload some Julia versions the next time they run this action.

By calling it a bugfix, we also don't need to create an opt-in mechanism, so the code surface becomes simpler.

@MichaelHatherly What do you think?

[DilumAluthge]

BTW, before merging, @krynju could you rebase on the latest main branch and squash everything into two commits - one commit with the main changes (but no changes to lib/* and dist/*), and a second commit with only the changes to lib/* and dist/*?

[krynju]

BTW, before merging, @krynju could you rebase on the latest main branch and squash everything into two commits - one commit with the main changes (but no changes to lib/* and dist/*), and a second commit with only the changes to lib/* and dist/*?

Done, the 2 changes requested are in too

[DilumAluthge]

Alright, here's my plan.

1. Make a release right before merging this PR.
2. Do one last review of this PR.
3. Merge this PR
4. Make another release right after merging this PR.

That way, if this does end up breaking someone's workflow, they can immediately revert back to the prior release.