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

[BUG] PREVIOUS_SHA & CURRENT_SHA is the same when re-running a workflow, causing changed-files to be empty #547

Closed
3 tasks done
YossiSaadi opened this issue Jul 18, 2022 · 8 comments · Fixed by #549
Closed
3 tasks done
Labels
bug Something isn't working

Comments

@YossiSaadi
Copy link

YossiSaadi commented Jul 18, 2022

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?

Action works great when running the workflow in the first attempt, but on the 2nd attempt and next, INPUT_PREVIOUS_SHA & INPUT_CURRENT_SHA are the same
This causes the changed-files to be empty.

So on 1st attempt, the checkout ref (of GH's Checkout action) is considered as the INPUT_CURRENT_SHA, and the real commit is INPUT_PREVIOUS_SHA.
on 2nd+ attempt, the checkout ref is considered as the INPUT_CURRENT_SHA, and INPUT_PREVIOUS_SHA is also this checkout ref.

This of course means that if we compare diff of same commit, any_modified would return false 😟

To Reproduce

  1. Create a workflow that using GH's checkout action
  2. Call the changed-files action
  3. Optional - Do something based on the info output (e.g. output the value of any_modified is true, and make it a condition for another job)

What OS are you seeing the problem on?

ubuntu-latest or ubuntu-20.04

Expected behavior?

any_modified should still be true if on 1st attempt it was true (and of course false if it was false on 1st attempt)

Relevant log output

COMMIT-SHA-0-PARENT -> master's latest commit before creating a branch
COMMIT-SHA-0 -> one commit in the new branch
COMMIT-SHA-1 -> result of ref GH's Checkout Action

* From GH's Checkout Action (it's the same on all re-run attempts (!)) *
  HEAD is now at COMMIT-SHA-1 Merge COMMIT-SHA-0 into COMMIT-SHA-0-PARENT
/usr/bin/git log -1 --format='%H'
'COMMIT-SHA-1'

* First Run (attempts/1) *

Successfully created paths-output-file: /tmp/***.txt
Run bash $GITHUB_ACTION_PATH/entrypoint.sh
  bash $GITHUB_ACTION_PATH/entrypoint.sh
  shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
  env:
    GITHUB_ACTION_PATH: /home/runner/work/_actions/tj-actions/changed-files/v23.1
    GITHUB_WORKSPACE: /home/runner/work/***/***
    INPUT_FILES_PATTERN_FILE: /tmp/***.txt
    INPUT_SEPARATOR:  
    INPUT_PATH: .
    INPUT_PREVIOUS_SHA: COMMIT-SHA-0
    INPUT_CURRENT_SHA: COMMIT-SHA-1
    INPUT_TARGET_BRANCH: refs/pull/9207/merge
    INPUT_CURRENT_BRANCH: refs/pull/9207/merge
    INPUT_QUOTEPATH: true
    INPUT_INCLUDE_ALL_OLD_NEW_RENAMED_FILES: false
    INPUT_OLD_NEW_SEPARATOR: ,
    INPUT_OLD_NEW_FILES_SEPARATOR:  
    INPUT_DIFF_RELATIVE: 
    INPUT_DIR_NAMES: false

* When clicking re-run for a workflow (attempts/2+) *

Successfully created paths-output-file: /tmp/***.txt
Run bash $GITHUB_ACTION_PATH/entrypoint.sh
  bash $GITHUB_ACTION_PATH/entrypoint.sh
  shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
  env:
    GITHUB_ACTION_PATH: /home/runner/work/_actions/tj-actions/changed-files/v23.1
    GITHUB_WORKSPACE: /home/runner/work/***/***
    INPUT_FILES_PATTERN_FILE: /tmp/***.txt
    INPUT_SEPARATOR:  
    INPUT_PATH: .
    INPUT_PREVIOUS_SHA: COMMIT-SHA-1
    INPUT_CURRENT_SHA: COMMIT-SHA-1 (same one)
    INPUT_TARGET_BRANCH: refs/pull/***/merge
    INPUT_CURRENT_BRANCH: refs/pull/***/merge
    INPUT_QUOTEPATH: true
    INPUT_INCLUDE_ALL_OLD_NEW_RENAMED_FILES: false
    INPUT_OLD_NEW_SEPARATOR: ,
    INPUT_OLD_NEW_FILES_SEPARATOR:  
    INPUT_DIFF_RELATIVE: 
    INPUT_DIR_NAMES: false

Anything else?

I think that it only happens for pull_request_review event

Code of Conduct

  • I agree to follow this project's Code of Conduct
@YossiSaadi YossiSaadi added the bug Something isn't working label Jul 18, 2022
@github-actions
Copy link
Contributor

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

@jackton1
Copy link
Member

jackton1 commented Jul 18, 2022

@YossiSaadi can you include screenshots from the checkout and the changed-files actions.

Example: #548 (comment)

Also, it would be helpful if you Included your current setup of the checkout action and changed-files action. Thanks.

Example:

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest  # windows-latest | macos-latest
    name: Test changed-files
    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@v23.1

@YossiSaadi
Copy link
Author

YossiSaadi commented Jul 18, 2022

Thanks for the super fast reply @jackton1 !

1st attempt

image

image

image

image

2nd attempt

image

image

image

image

image

workflow file

name: E2E tests

on:
  workflow_run:
    workflows: [ "Publish" ]
    types:
      - completed
  pull_request_review:
    types:
      - submitted
  pull_request:
    types:
      - labeled
  schedule:
    - cron: '0 0 * * *'
  workflow_dispatch:

jobs:
  should-e2e-run:
    if: github.event_name == 'workflow_run' || github.event_name == 'schedule' || github.event_name == 'workflow_dispatch' || (github.event_name == 'pull_request_review' && github.event.review.state == 'approved') || (github.event_name == 'pull_request' && github.event.action == 'labeled' && github.event.label.name == 'run-e2e')
    timeout-minutes: 1
    runs-on: ubuntu-latest
    outputs: 
      should_run: ${{ steps.output-should-run.outputs.should_run }}
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Get specific changed files
        id: pr-changed-files
        uses: tj-actions/changed-files@v23.1
        with:
          files: |
            src/app/**
            src/shared/**
            package.json
            yarn.lock
            babel.config.js
            public/**
            .github/workflows/test_e2e.yml
      
      - name: Set if should run E2E
        env:
         should_run: | 
          ${{ steps.pr-changed-files.outputs.any_modified == 'true' || 
              github.event_name == 'workflow_run' ||
              github.event_name == 'schedule' ||
              github.event_name == 'workflow_dispatch'
          }}
        id: output-should-run
        run: |
          echo "::set-output name=should_run::${{ env.should_run }}"
  build:
    if: ${{ needs.should-e2e-run.outputs.should_run == 'true' }}
    timeout-minutes: 8
    runs-on: ubuntu-latest
    needs: should-e2e-run
    steps:
      - name: Checkout
        uses: actions/checkout@v3

Don't mind the amount of checks, it's a wip :)
Wanted to give you the original file with no changes, to see if I'm missing something else

@jackton1
Copy link
Member

jackton1 commented Jul 18, 2022

@YossiSaadi from the workflow file above I see that you're missing the fetch-depth input which defaults to 1 if not set https://github.com/actions/checkout/blob/main/action.yml#L56.

I think the best solution for this would be to compare the commit hashes and raise an exception if they are the same which appears to be the case when the local copy only has at most 1 commit history.

Proposed solution

Change

     - name: Checkout
       uses: actions/checkout@v3

To

     - name: Checkout
       uses: actions/checkout@v3
       with: 
          fetch-depth: 2

@jackton1 jackton1 linked a pull request Jul 18, 2022 that will close this issue
@YossiSaadi
Copy link
Author

@jackton1 it seems by the logs that checkout does its job properly and checkout to a ref as it should, same result as on first attempt.

Can it still be the reason?

@jacktony1
Copy link
Contributor

@YossiSaadi This should be resolved in the latest release v23.2

@YossiSaadi
Copy link
Author

@YossiSaadi This should be resolved in the latest release v23.2

Thank you so much, I really appreciate the effort and the quick reply 🙏🏻😎

@jackton1
Copy link
Member

Your welcome

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
3 participants