[BUG] Auto-Merge not working properly on Change-Detection for PRs

[fdc-viktor-luft]

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?

Instead of failing, I get as output for the "all_modified_files" this:

::error::Failed to get changed files between: 0903c9c360a0a00c60e6d03e50129edac363f85d...b16e131872126cf3dd0201883f7a6ad547a94413

Expecting a list of space separated file names, this was causing a severe issue skipping several checks in our CI.

To Reproduce

I'm using the action in a very basic way. Example workflow:

name: PR

on:
  pull_request:

jobs:
  prepare-targets:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - id: files
        uses: tj-actions/changed-files@v34.0.0
      - run: echo "${{ steps.files.outputs.all_modified_files }}"

What OS are you seeing the problem on?

ubuntu-latest or ubuntu-20.04

Expected behavior?

In version v29.0.7 everything still worked fine.

Relevant log output

No response

Anything else?

I'm not sure if the above issue was caused by some Auto-Merge as I had to fast react and rollback the change, but...

I also tried v32.1.2. In that version is already another issue. Whenever the Auto-Merge runs the "all_modified_files" contains also all touched files from Auto-Merge instead of only files touched in the PR.

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 if you haven't already to help us reach a wider audience.

[jackton1]

@fdc-viktor-luft Can you also include a complete log output with debug logging enabled?

This can be done by:

• Re-running the workflow with (debug logging enabled)

AND

• Downloading the log archive

[fdc-viktor-luft]

I'll see if the log doesn't contain any sensitive data. In that case I'd be happy to share it. I'll try to find some time to do that 👍

[hhelmken]

We are experiencing a quite similar error right now. Here's the relevant log output of this step:

changed-files
  Resolving repository path: /opt/actions-runner/_work/owner/repository/.
  Retrieving changes between bc70d097fcbdeb1b34a37ef5d21256bb4fd3b93f (master) → dc0d09c45c364d45d3381461040aa46ee1ea6b60 (dependabot/terraform/subfolder/hashicorp/aws-4.37.0)
  fatal: bc70d097fcbdeb1b34a37ef5d21256bb4fd3b93f...dc0d09c45c364d45d3381461040aa46ee1ea6b60: no merge base
  fatal: bc70d097fcbdeb1b34a37ef5d21256bb4fd3b93f...dc0d09c45c364d45d3381461040aa46ee1ea6b60: no merge base
  fatal: bc70d097fcbdeb1b34a37ef5d21256bb4fd3b93f...dc0d09c45c364d45d3381461040aa46ee1ea6b60: no merge base
  fatal: bc70d097fcbdeb1b34a37ef5d21256bb4fd3b93f...dc0d09c45c364d45d3381461040aa46ee1ea6b60: no merge base
  fatal: bc70d097fcbdeb1b34a37ef5d21256bb4fd3b93f...dc0d09c45c364d45d3381461040aa46ee1ea6b60: no merge base
  fatal: bc70d097fcbdeb1b34a37ef5d21256bb4fd3b93f...dc0d09c45c364d45d3381461040aa46ee1ea6b60: no merge base
  fatal: bc70d097fcbdeb1b34a37ef5d21256bb4fd3b93f...dc0d09c45c364d45d3381461040aa46ee1ea6b60: no merge base
  fatal: bc70d097fcbdeb1b34a37ef5d21256bb4fd3b93f...dc0d09c45c364d45d3381461040aa46ee1ea6b60: no merge base
  fatal: bc70d097fcbdeb1b34a37ef5d21256bb4fd3b93f...dc0d09c45c364d45d3381461040aa46ee1ea6b60: no merge base
  fatal: bc70d097fcbdeb1b34a37ef5d21256bb4fd3b93f...dc0d09c45c364d45d3381461040aa46ee1ea6b60: no merge base
  fatal: bc70d097fcbdeb1b34a37ef5d21256bb4fd3b93f...dc0d09c45c364d45d3381461040aa46ee1ea6b60: no merge base
  fatal: bc70d097fcbdeb1b34a37ef5d21256bb4fd3b93f...dc0d09c45c364d45d3381461040aa46ee1ea6b60: no merge base
  fatal: bc70d097fcbdeb1b34a37ef5d21256bb4fd3b93f...dc0d09c45c364d45d3381461040aa46ee1ea6b60: no merge base
  fatal: bc70d097fcbdeb1b34a37ef5d21256bb4fd3b93f...dc0d09c45c364d45d3381461040aa46ee1ea6b60: no merge base

I'd expect the check to fail, instead any_changed results apparently to true as our following steps are skipped. In this example there was a file change in this specific folder.

[jackton1]

@hhelmken @fdc-viktor-luft @MichaelBrandt4994 This issue has been resolved in the latest release.

[fdc-viktor-luft]

@jackton1 Thank you a lot. Will give a try soon.

[fdc-viktor-luft]

@jackton1 I tried it and it doesn't work properly. We will provide you with more information and re-create an issue with the updated logs.

With a PR containing only a single commit we see this error:

  Resolving deltas: 100% (100828/100828), completed with 1208 local objects.
  From https://github.com/***/***
     b41e7b7b81..23e11bb325  master     -> master
     b41e7b7b81..23e11bb325  master     -> origin/master
  Error: Unable to find merge-base in shallow clone. Please increase 'max_fetch_depth' to at least 180.
  Error: Process completed with exit code 1.

[ericLemanissier]

@jackton1 did you consider using github api to get the changed files in case of Pull Requests ? Here is a dumb example of an action implementing a subset of the inputs/outputs of your action, in a robust way (only for PRs though) https://github.com/ericLemanissier/conan-center-index/blob/patch-5/.github/actions/pr_changed_files/action.yml

[jackton1]

@ericLemanissier @fdc-viktor-luft

I suggest a simple fix using the documentation.

Change

- uses: actions/checkout@v3

To

- uses: actions/checkout@v3
   with:
       fetch-depth: 0

Also, can you confirm that you are using v34 instead of v34.0.0?

[jackton1]

We will provide you with more information and re-create an issue with the updated logs.

This is the only secret to finding a solution to the issue as excerpts from logs are not helpful a full picture of how the problem occurred would be more valuable or optionally replicating the problem in another repository that isn't private.

[fdc-viktor-luft]

Isn't fetch-depth: 0 way less efficient for the actions/checkout? 🤔