Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tool-cache: Use --force-local for tar on Windows #165

Closed
wants to merge 1 commit into from
Closed

tool-cache: Use --force-local for tar on Windows #165

wants to merge 1 commit into from

Conversation

Ecco
Copy link

@Ecco Ecco commented Sep 30, 2019

The extractTar nearly works on Windows, except that it cannot deal with absolute path.
Indeed, C:\foo\bar is interpreted as a remote path by tar by default.

@bryanmacfarlane
Copy link
Member

Thanks! Can you include a workflow with a repro? I want to validate with and without your changes.

@Ecco
Copy link
Author

Ecco commented Oct 3, 2019

Hi! I'm not sure what you're asking for exactly.

My understanding is that a workflow.yml is not going to use this directly. But another action may use tool-cache as a dependency.

As far as a test case could go, I think this should do the trick:

const myArchive = await tc.downloadTool("http://host.com/path/to/tarball.tgz");
const archiveExtractedFolder = await tc.extractTar(node12Path, ".");

@Ecco
Copy link
Author

Ecco commented Oct 3, 2019

Note that when testing this patch you might also get hit by #180 which is yet another bug on Windows 😄

@mroch
Copy link

mroch commented Oct 19, 2019

thanks for this! it (and #180) were necessary for me too.

// On Windows, absolute path use a ':' (e.g. C:\foo), which is incorrectly recognized as a remote path by tar unless this flag is passed
args.push('--force-local')
}
args.push('-C', dest, '-f', file)
Copy link
Contributor

@ericsciple ericsciple Dec 7, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to C:\windows\system32\tar.exe --help the option -C is only for create, it is not a common option.

Also @joshmgross informed me bsd tar does not support --force-local. And C:\windows\system32\tar.exe is bsd tar.

Instead of -C I think dest should be the working directory (exec option).

Thoughts?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I see. Because of the other file path 🤦

The problem is the hosted machines prepend the gnu tools to the PATH, rather than append to the PATH.

Self hosted runners would more commonly have %windir%\System32\tar.exe (bsd tar) in the PATH.

And bsd tar works correctly. It also doesn't require forward slashes.

I think the correct solution is: on Windows don't which tar.

Instead do:

`${process.env['windir']}\\System32\\tar.exe`

If tar doesn't exist at that location, fail.

Thoughts?

Copy link

@eine eine Dec 9, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ericsciple, thanks for the details. If that is the case, I think that more effort is required than just fixing if (IS_WINDOWS) in this repo:

  • The toolkit should provide a tar command that would hide the inconsistencies in the implementation of the runners from the user. Not using which has the side effect that the arguments might need to be explicitly different for windows-latest, ubuntu-latest and macos-latest.
  • Your comment about gnu tools being prepended to the default (bsd flavour), should be added to the docs as an important warning.

Then, it will be up to action developers to use the command or to handle it with custom logic.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dont like the solution i proposed anymore. @thboop good point that it doesnt cover older windows which the runner supports.

Copy link
Contributor

@ericsciple ericsciple left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see comment

@dhouseatx
Copy link

dhouseatx commented Dec 7, 2019 via email

@ericsciple
Copy link
Contributor

@Ecco @mroch @eine also curious about the scenario. Many tools offer multiple archive formats for users on different platforms (zip or 7z for Windows)

And the tar command doesn't exist on older versions of Windows (which are supported by self hosted runners)

@eine
Copy link

eine commented Dec 16, 2019

@ericsciple, the scenario is numworks/setup-msys2:

https://github.com/numworks/setup-msys2/blob/0cf6aff498679e8ce523121a8e8839ab8d26277f/index.js#L24-L31

See also numworks/setup-msys2#23.

The big picture is that the bash shell provided in windows-latest seems to be some limited variant of MINGW installation, such as Git for Windows. Therefore, it lacks pacman and the ability to add other MSYS2/MINGW32/MINGW64 packages. Being able to use pacman (install additional dependencies) is a requirement to build PKGBUILD files on windows-latest GHA jobs. There are currently at least ~1500 tools available as PKGBUILD files for MSYS2: https://github.com/msys2/MINGW-packages.

As commented in actions/starter-workflows#95, this is, overall, the best but limited workaround we can use to overcome the fact that GHA are not MSYS2-friendly at all. Should GitHub provide built-in msys2, mingw64, mingw32 and/or wsl shells (instead of just bash), many related issues would be fixed: #232, numworks/setup-msys2#21, numworks/setup-msys2#22, etc.

Many tools offer multiple archive formats for users on different platforms (zip or 7z for Windows)

Unfortunately, pre-built versions of MSYS2 are distributed as tar.xz only (http://repo.msys2.org/distrib/x86_64/). Is it possible to extract it with any other tool available in windows-latest which is not tar?

As commented in https://github.community/t5/GitHub-Actions/Windows-MSYS2-Ruby/m-p/33946/highlight/true#M1727, before using setup-msys2, I was using chocolatey to install MSYS2. However, it takes 5min to do so. setup-msys2 needs around 30s.

And the tar command doesn't exist on older versions of Windows (which are supported by self hosted runners)

I don't think this is an issue, since maintainers of self-hosted runners can (should) install MSYS2 as part of the base image. Hence, step setup-msys2 might just be skipped.

@ericsciple
Copy link
Contributor

@eine thanks, that helps. I checked - { shell: cmd, run: where bash } and it looks like only Git Bash is installed. WSL Bash not installed at all, I was a little surprised but maybe related to HDD size constraints 🤷‍♂. Note the repo for the images is here: https://github.com/actions/virtual-environments

@eine
Copy link

eine commented Dec 17, 2019

@joshmgross
Copy link
Member

Fixed by #264

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants