Thanks for finding that! Next time we find unexpected runs, I’ll look to see if this explains it.

I’m still lost, I have a similar problem. All I want is to run codeql-analysis.yml when it matters:

I have my master branch.

I created a feature branch and opened a PR to master branch.

During a cycle, I may change python files in folderA. In another push I may only change docs. And so on. Right now, whatever I try to set up in my eg. .github/workflows/codeql-analysis.yml, it will run anyway after any push I do to branch feature and I don’t want this happen.

I don’t want all my workflow checks to run unless I change something in two specific folders, say folderA and folderB, where I have my *.py files.

So, whenever I change something in docs or even .github/workflows/*.yml but not changing anything about *.py in one of the mentioned folders, I don’t want the workflow to run whenever I do a push!

I have this for my .github/workflows/codeql-analysis.yml:

name: "CodeQL"
on:

push:

branches: [master]
pull_request:

branches: [master]

paths:

- "folderA/"

- "folderB/"

schedule:

- cron: "15 0 * * *"

...

So how can I tweak my codeql-analysis.yml to run it only when it matters?

There are some github actions that probably try to help here. (I’m fairly certain I’ve seen some that will help with this.)

A quick search shows:

  <a href="https://github.com/tj-actions/changed-files" target="_blank" rel="noopener nofollow ugc">GitHub</a>

GitHub - tj-actions/changed-files: Github action to retrieve all (added,...

Github action to retrieve all (added, copied, modified, deleted, renamed, type changed, unmerged, unknown) files with support for push and pull request events. - GitHub - tj-actions/chang...

To make it work would require a bit of magic, since you’d have to fish for the previous head value.

I’m fairly certain it’s floating around, in fact, check-spelling has some magic for it:

  <a href="https://github.com/check-spelling/check-spelling/blob/d3e67e88f93da3534317e3cafc06a387bd7daed3/unknown-words.sh#L963-L980" target="_blank" rel="noopener nofollow ugc">github.com</a>

check-spelling/check-spelling/blob/d3e67e88f93da3534317e3cafc06a387bd7daed3/unknown-words.sh#L963-L980

    
      

          
if to_boolean "$INPUT_ONLY_CHECK_CHANGED_FILES"; then
          
  COMPARE=$(cat "$GITHUB_EVENT_PATH" | jq -r '.compare // empty' 2>/dev/null)
          
  if [ -n "$COMPARE" ]; then
          
    BEFORE=$(echo "$COMPARE" | perl -ne 'if (m{/compare/(.*)\.\.\.}) { print $1; } elsif (m{/commit/([0-9a-f]+)$}) { print "$1^"; };')
          
    BEFORE=$(curl -s \
          
      -H "$AUTHORIZATION_HEADER" \
          
      "$GITHUB_API_URL/repos/$GITHUB_REPOSITORY/commits/$BEFORE" | jq -r '.sha // empty')
          
  elif [ -n "$GITHUB_BASE_REF" ]; then
          
    BEFORE=$GITHUB_BASE_REF
          
  fi
          
fi
          
if [ -n "$BEFORE" ]; then
          
  echo "Only checking files changed from $BEFORE" >&2
          
  git fetch origin $BEFORE >/dev/null 2>/dev/null
          
  git diff -z --name-only FETCH_HEAD..HEAD
          
else
          
  INPUT_ONLY_CHECK_CHANGED_FILES=
          
  git 'ls-files' -z 2> /dev/null
      
    
  

(I’m not sure you’d really want to try to understand that black magic.)

But, the code is there to support this feature:

  <a href="https://github.com/check-spelling/check-spelling/blob/d3e67e88f93da3534317e3cafc06a387bd7daed3/action.yml#L130-L131" target="_blank" rel="noopener nofollow ugc">github.com</a>

check-spelling/check-spelling/blob/d3e67e88f93da3534317e3cafc06a387bd7daed3/action.yml#L130-L131

    
      

          
only_check_changed_files:
          
  description: 'If set, only check files changed since the last push'
      
    
  

Essentially you’ll be writing a workflow that will run, and it will use run some action to decide which files have changed since the last push, and then the later steps will be skipped.

That said…

The naive solution is “don’t mix doc changes with code changes unless you want to have testing recheck”. That is a valid approach, although it means you now get 2 PRs, one to add a feature and one to document the feature.