While this would fix the issue we have on the jira ticket i have the feeling this is becoming a bit too magic, since we don't match anymore the actual revision for files changes but another different revision which could be a surprise for some user.

I am actually thinking we should revert the file change works and let the user configure their repo to don't do merge but rebase if they want to file matching...

wdyt @zakisk

While this would fix the issue we have on the jira ticket i have the feeling this is becoming a bit too magic, since we don't match anymore the actual revision for files changes but another different revision which could be a surprise for some user.

I am actually thinking we should revert the file change works and let the user configure their repo to don't do merge but rebase if they want to file matching...

wdyt @zakisk

yeah, rebasing should be first choice and I think we should hardcore this requirement that PaC requires rebase policy for Bitbucket Data Center as commit SHA is PaC's pivotal field.

I think that's fair if we want to be consistent with only looking at the pushed commit. In that case, we should also clarify the documentation about how paths-changed behaves. Right now our docs don't really specify how it behaves in edge cases.

Currently only the changes included in the HEAD commit of the push event are considered by paths-changed, but that's not currently documented. In contrast to something like Github Actions, all commits in the push event are considered. IME users usually expect the latter behavior and often require an explanation when the PLR doesn't match.

Both of these jobs effectively clone the repository when someone pushes changes to any markdown files in the repo root. Here

# .github/workflows/on-push.yaml
name: Do some stuff
on:
  push:
    paths:
      - "*.md"
jobs:
  do-stuff:
    runs-on: ubuntu-latest
    steps:
      - name: checkout repo
        uses: actions/checkout@v3

---
apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: test
  annotations:
    pipelinesascode.tekton.dev/on-event: "[push]"
    pipelinesascode.tekton.dev/on-paths-changed: "[*.md]"
spec:
  params:
    - name: repo_url
      value: "{{repo_url}}"
    - name: revision
      value: "{{revision}}"
  workspaces:
    - name: dir
      emptyDir: {}
  pipelineSpec:
    params:
      - name: repo_url
      - name: revision
    workspaces:
      - name: dir
    tasks:
      - name: clone-repository
        params:
        - name: url
          value: $(params.repo_url)
        - name: revision
          value: $(params.revision)
        taskRef:
          name: git-clone
        workspaces:
          - name: output
            workspace: dir

Some different push commands and how they behave:

regular push

# Both PaC and GH trigger
$ echo "bump" >> README.md && git add README.md && git commit -m 'update md file'
$ git push

multi-commit push

# GH triggers, PaC does not 
$ echo "bump" >> README.md && git add . && git commit -m 'update md file'
$ echo "bump" >> non-markdown.txt && git add . && git commit -m 'update non markdown'
$ git push

merge commit

# starting on the main branch
$ git checkout -b other-branch
$ echo "bump" >> README.md && git add . && git commit -m 'update md file'
# triggers GH and PaC on other-branch
$ git push 

$ git checkout main
$ git merge --no-ff other-branch
# Note the `--no-ff` ensures the Merge Commit does not have the markdown changes
$ git diff *.md
# triggers GH but not PaC
$ git push main

rebase

$ echo "bump" >> README.md && git add . && git commit -m 'update md file'
# triggers GH and PaC
$ git push 
$ echo "bump" >> non-markdown.txt && git add . && git commit -m 'update non markdown'
# triggers neither GH nor PaC
$ git push

# rebase to drop the 'update md file' commit
$ git rebase -i HEAD^^^

# Neither GH nor PaC count as "changing *.md
$ git push --force-with-lease

It seems like Github in all cases (maybe except for rebasing) GH compares the new HEAD commit (event.after) to the previous HEAD commit (event.before, whereas PaC looks at the new HEAD commit alone to get the file changes. I personally think comparing the previous and new HEAD would be preferable, but that would be a notable change and the documentation should be clarified either way

I personally think comparing the previous and new HEAD would be preferable, but that would be a notable change and the documentation should be clarified either way

I don't think any logic comparing previous HEAD and current? does GitHub actions really does that? do you any reference?

I don't think any logic comparing previous HEAD and current? does GitHub actions really does that? do you any reference?

@zakisk Each of the above examples were tested to confirm the behavior before I posted. Since rebasing to drop a commit doesn't appear to trigger the runs maybe comparing the previous HEAD and new HEAD isn't accurate, but GHA does at least check the changed files of every commit included in the push event