0
votes

I have set up two github workflows, which are run by two different self-hosted runners. With both runners, running the checkout@v2 action results in certain 'large' downloaded files to become oversized. Eg. a 512 kb png image in the repo becomes 514 kb when downloaded using the action, or a 1331 kb .exe file becomes 1355 kb. When said .exe is run, powershell cancels the program with 'applicationfailedexception'.

Here is a snippet from one of the workflows:

jobs:
  benchmark:
    runs-on: [self-hosted, Windows, X64]

    steps:
      - uses: actions/checkout@v2
        with:
          submodules: true

      - name: Execute Premake
        run: .\premake5.exe vs2019

There are more steps than these, but the runs fail at the second step; 'Execute Premake', since the .exe is 'corrupted' or 'oversized' after checking out in the first step.

This only happens with some of the large files. All the smaller ones, ie. source code, are fine. When running git status in the action runner's cloned action runner, the 'corrupted' files are seen as modified.

The self-hosted runners are both running x64 windows. Any thoughts on what could be wrong? I'm thinking of replacing the checkout action with manual calls to git.

1
Is it possible AV on your runner is interfering? Does the binary appear as "blocked" if you right click and view the properties of it or something? - codaamok

1 Answers

1
votes

Git is treating the files as text, replacing each Unix line ending byte 0A (LF in ASCII) with the Windows linebreak bytes 0D 0A (CR LF).

Because all bytes are equally likely in well-compressed file format such as PNG, this will increase the size of the file by 1 byte for every 256 on average – which is exactly what you're seeing. (The reverse transformation would reduce the file by 1 in 65536.)

Incidentally, PNG's header is designed to detect this and similar types of file transfer corruption, with the sequence 0D 0A 1A 0A.

As for preventing the corruption, try using a .gitattributes file to mark the files as binary.