[BUG] "Unable to locate the current sha" when using use_fork_point

[dmohns]

Is there an existing issue for this?

• I have searched the existing issues

Does this issue exist in the latest version?

• I'm using the latest release

Describe the bug?

Running changed-files action one a large mono repo "sometimes" yields

 Warning: Unable to locate the previous sha: 
  Warning: You seem to be missing 'fetch-depth: 0' or 'fetch-depth: 2'. See https://github.com/tj-actions/changed-files#usage

in an un-reproducible way. Sometimes rebasing and force-pushing fixes it, sometimes merging main fixes it. But also sometimes neither of them does.

The configuration I use is

jobs:
  sqlfluff:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0  # OR "2" -> To retrieve the preceding commit.
      - name: Get changed files
        id: changed-files
        uses: tj-actions/changed-files@v20
        with:
          use_fork_point: "true"

Note how previous sha is empty. Unfortunately this happens in private repos and I cannot share the exact workflow run.

To Reproduce

Unfortunately, I couldn't find a way to reproduce this error 100% of the time.

What OS are you seeing the problem on?

ubuntu-latest or ubuntu-20.04

Expected behavior?

changed-files should work on every workflow run.

Relevant log output

Resolving repository path...
  Getting HEAD SHA...
  Getting fork point...
  From https://github.com/***
   * [new branch]            main       -> main
  Verifying commit SHA...
  Warning: Unable to locate the previous sha: 
  Warning: You seem to be missing 'fetch-depth: 0' or 'fetch-depth: 2'. See https://github.com/tj-actions/changed-files#usage
  Error: Process completed with exit code 1.

Anything else?

PS: Converted from a comment in #458 as I think it's a different issue.

Code of Conduct

• I agree to follow this project's Code of Conduct

[github-actions]

Thanks for reporting this issue, don't forget to star this project to help us reach a wider audience.

[dmohns]

I have been doing "some" investigation (or trial and error rather). I'm not a git expert, so not sure if any of the following makes sense 😉

The documentation of git merge-base notes a couple of caveats about using the --fork-point mode. I.e. git gc was mentioned. I saw we are running git merge-base --fork-point, but I don't fully understand why.

I have been testing to run changed-files without using --fork-point like so

      - name: changed-files Github Action SHA workaround
        id: changed-files-sha-workaround
        run: |
          git fetch --no-tags -u --progress origin "main":"main"
          CURRENT_SHA=$(git rev-list --no-merges -n 1 HEAD 2>&1)
          echo "Current SHA: $CURRENT_SHA"
          FORK_POINT=$(git name-rev --name-only "$CURRENT_SHA")
          echo "Fork point: $FORK_POINT"
          PREVIOUS_SHA=$(git merge-base "main" "$FORK_POINT")
          echo "Previous SHA: $PREVIOUS_SHA"
          echo "::set-output name=current_sha_workaround::$CURRENT_SHA"
          echo "::set-output name=previous_sha_workaround::$PREVIOUS_SHA"
      - name: Get changed files
        id: changed-files
        uses: tj-actions/changed-files@v20
        with:
          sha: ${{ steps.changed-files-sha-workaround.outputs.current_sha_workaround }}
          base_sha: ${{ steps.changed-files-sha-workaround.outputs.previous_sha_workaround }}

and it seems to be working.

While running with --fork-point yielded

Error: Process completed with exit code 1.

One other thing I noted is, that in the repository I'm working with we use tags very heavily. Also, it's a relatively large repo with a lot of commits. I was wondering if tagging might have some negative influence on how --fork-point works.

[zhakanov]

is it possible to count all the changed files?

[dmohns]

After more investigation it doesn't look like the problem is actually related to this Github Action.

For some reason $(git rev-list --no-merges -n 1 HEAD 2>&1) sometimes returns the latest commit on the main branch. I suspect this is some weird interaction between how our repository is managed and the checkout action.

I'm closing this, as I don't think there is anything that can be done here.