Long commit list passed to git rev-list raises an exec error

[jmhobbs]

On repositories with a large history (example was 160k+ commits) the git rev-list command here can have too many arguments to execute cleanly, throwing an E2BIG error.

From the exec(2) docs, E2BIG is:

The number of bytes in the new process's argument list is greater than the system-imposed limit of ARG_MAX bytes. The argument list limit is sum of the size of the argument list plus the size of the environment's exported shell variables.

The configuration valueARG_MAX is available via getconf / sysconf.

Two workarounds to this problems:

• Use a shallow clone of the repository (this will lead to the build not having any baselines.
• Remove the project and re-add it (this will remove all baselines).

Both workarounds might make sense if indeed the scenario is a project that hasn't had a Chromatic build in some time (see comment below).

[tmeasday]

In theory this shouldn't happen because we should only search the commits backwards as far base as the latest build OR to the timestamp of the first build we have for the repo.

I think what's happening here is that the repo in question is both very large and has been inactive for a quite a while, leading to a large number of commits since the last Chromatic build.

We should probably just bail out of finding the parent commit in this rare case (when the commits list gets too long) and warn the user that as a result of that we are running a build with no baseline. A baseline from a build months ago is probably not super useful anyway.

[toljaEmbroker]

Hi, can you explain please why do you need fetch-depth: 0 here: https://github.com/chromaui/action#checkout-depth Is there another solution to this, since we have a big project. (7 years, 62k commits)

We only trigger this on develop branch and PRs that are going to develop. So would it be enough to get commits for that PR and develop?

[chantastic]

The fetch-depth: 0 config ensures the history is there. action/checkout defaults to only a single commit.

At the moment there is recommended method for working with partial history.

[toljaEmbroker]

Thanks, @chantastic for the feedback, I'm just wondering if fetch-depth:0 is just easier or we can do something like this

            # Make sure that we fetch all of the required git history.
            #
            - name: Inspect changeset
              env:
                  COMMITS_JSON: ${{ toJson(github.event.commits) }}
              run: |
                  echo "FETCH_DEPTH=$(echo $COMMITS_JSON | jq '. | length | . + 1')" >> $GITHUB_ENV
            - name: Checkout project
              uses: actions/checkout@v2
              with:
                  fetch-depth: ${{ env.FETCH_DEPTH }}

Will that be enough for Chromatic, or is it necessary to have history from all the branches as well.

[tmeasday]

@toljaEmbroker you'd just want to be sure there's a Chromatic build within FETCH_DEPTH commits. If there isn't, things will be broken.

If you don't want to set it to 0, I would recommend a minimum of some fairly high number, maybe 50?