@actions/tool-cache downloadTool does not save file with file extension about toolkit

[warrenbuckley]

Hi @damccorm
Thanks for the reply and your train of thought on this.

If you keep it as it is, then I suggest more detailed docs & end to end examples on the page listed here - https://github.com/actions/toolkit/tree/master/packages/tool-cache#download

There is no mention that this will download the file as a GUID with no file extension & that I should use the cachePath method, as not all tool files are always .zip, .7z or .tar's

As you do not run into the filename extension problem if your tool is an archive as it expands the file without an extension regardless, which most of the setup-node, setup-go actions/repos use.

I would have only discovered the correct usage of this by asking you politely for a pointer/advice, so I recommend docs & examples are updated to show how you want people to use/consume the APIs.

[stephenmichaelf]

@damccorm Yes I will take this one.

What if we were to allow an optional parameter that specifies a filename/path? We can default to the UUID if the filename is not present. Since it's an optional param it still encourages people to only use it if needed.

I think we should have these follow up items:

• Improve documentation of downloadTool here to additionally describe both how it works and what options the user has
• Enhance implementation to add the optional file name

@warrenbuckley @damccorm Would that work?

[warrenbuckley]

Any update/progress on this at all?

[damccorm]

Actually implementing this should be fairly trivial. We just need to change this line to append the final part of destPath instead of a uuid. It shouldn't break anyone since the path is already randomized so no one could have taken a dependency on the path itself.

So then I guess the only question is do we want to do this? I'm not completely convinced that we do. My main rationale for keeping it as is would be that it encourages good patterns - namely it encourages people to move it out of the temp directory/cache it.

I guess we'd also need to figure out what we want to do in the case of collisions (e.g. what if you try to download 2 versions of nuget.exe - one perk of our current approach is that it allows you to do this in parallel).

Maybe a better solution would be to allow users to specify their own destPath - so we keep the default behavior, but allow you to download it somewhere else if you see fit (e.g. $HOME/myExecutable.exe)? Thoughts?

[damccorm]

If you keep it as it is, then I suggest more detailed docs

Yep, seems like regardless of what we do, better docs are a must here. I think I like the solution of allowing users to specify their own destination path. @stephenmichaelf any thoughts/do you want to take this one?

[damccorm]

That sounds good to me.