Commits filtering confusion with multiple commits

[IlyaFinkelshteyn]

When change contains multiple commits, filtering rules can behave not as people expect. Problem is that we are taking commit details (such as message, author, or changed files) from the head commit, not from each one included.

Scenarios:

1. Multiple commits made locally and pushed once to GitHub
2. Multiple commits made in the branch development and merged (without a PR) to the branch master
3. Multiple commits made in the branch development and PR is sent to the branch master

In cases 1 and 2, we can read all commits details from incoming webhook content.

In case 3 we need to call GitHub API for each included commit which can be very expensive.

Also, we need to get better understanding of possible side effects if we start collecting details from all commits.

For now, workaround recommendation is to squash commits before push or merge.

[eamodio]

It would be great to at least have #1 fixed -- that is the biggest issue we face today.

[IlyaFinkelshteyn]

@eamodio could you please elaborate what kind of filtering do you use? Commit messages?

[eamodio]

We use skip_commits files

[IlyaFinkelshteyn]

@eamodio and your build is being triggered when you expect it to be skipped?

[eamodio]

The other way around -- if a dev pushes a set of commits, only the last commit is used to determine what is built.

[Methuselah96]

@IlyaFinkelshteyn For the third scenario, can the "List pull request files" from the GitHub API (https://developer.github.com/v3/pulls/#list-pull-requests-files) be used?

[IlyaFinkelshteyn]

@Methuselah96 looking into this

[brianbraeckel]

Any update on this? I seem to be hitting this issue today, and it breaks the skip_commits for our purposes. I can't use the feature if some PRs randomly don't trigger builds because the latest commit happened to be skipped.

[FeodorFitsner]

@brianbraeckel could you describe your case in more details please? What was the filter in skip_commits?

[brianbraeckel]

Sure. It seems to be the same as listed above, but this is an old GitHub issue, so it could be different.

1. I have a skip_commits with a files attribute like the following:

skip_commits:
  files:
    - src/some_dir/
    - some_file.yml

2. Builds are correctly triggered for commits that include any files outside of these exclusions.
3. Builds are correctly skipped for commits where all changed files fall under the skip_commits section.
4. There seems to be a problem when there are multiple commits sitting in a staging branch, the latest of which is composed entirely of skipped files, and a PR is created from that staging branch to another branch.

I haven't exhaustively tested it yet, but it appeared the same as the issue described in this thread (i.e. if the latest commit sitting in the staging branch is entirely skipped files, then the PR does not trigger an AppVeyor build even if there are other commits that include non-skipped changes), so I figured I'd post here first.

Thanks!

[bedej]

Hi - any update here?

I am a colleague of @brianbraeckel and this bug makes commit filtering unusable for us. Scenario #3 is especially bad. It seems to me that this feature is pretty broken in the current state. I'm actually not sure what case it would be usable. I guess if you had commits and PRs from developers who each only ever worked in one part of the code (either the filtered in or the filtered out part), but never in both, then it would work as expected. For all other cases, it is broken and causes missed builds, and thus it can't be used.

Is there any workaround other than moving the filtered code to a different repository completely?