The 0.0.2 version of this orb does not respect the [skip ci] or [ci skip] tags in a commit message. See CircleCI docs on skipping here.
This PR removes any commits with a skip tag from the list prior to the mappings being checked.
Note: When using a git log --name-only command, its not possible to format the output of the changed files list in to an easily parsable format along with the commit hash and messages (eg. all on one line). Instead I've opted to fetch the list of commits first, then filter out the ones to be skipped, then loop through the list of remaining commits getting the changed files for each of them. This is less performant as it will be making an additional subprocess run call to git per commit but seemed like a more robust way to do it that involved less text parsing.
Motivation:
In the following scenario I would expect that the paths of files changed in commits with the [skip ci] tag would NOT return parameters as true after a subsequent commit that does not change files matching the same mapping.
In version 0.0.2, this issue can be reproduced as follows...
Commit 1 makes a change to a file at the path path1/file1 and uses the [skip ci] message tag. This change is pushed to the repo first and the build is skipped as intended.
Commit 2 makes a change to a file at the path path2/file2. This change is pushed to the repo after Commit 1 and the setup workflow is triggered with path based filtering. The v0.0.2 path filter currently returns the parameters for both path1-parameter AND path2-parameter as true.
In this example with the current logic, this will potentially cause workflows or jobs to run in the continuation config based on path1-parameter that were not intended to be run at the time Commit 2 was pushed.
Description
The 0.0.2 version of this orb does not respect the [skip ci] or [ci skip] tags in a commit message. See CircleCI docs on skipping here.
This PR removes any commits with a skip tag from the list prior to the mappings being checked.
Note: When using a
git log --name-onlycommand, its not possible to format the output of the changed files list in to an easily parsable format along with the commit hash and messages (eg. all on one line). Instead I've opted to fetch the list of commits first, then filter out the ones to be skipped, then loop through the list of remaining commits getting the changed files for each of them. This is less performant as it will be making an additional subprocess run call to git per commit but seemed like a more robust way to do it that involved less text parsing.Motivation:
In the following scenario I would expect that the paths of files changed in commits with the [skip ci] tag would NOT return parameters as
trueafter a subsequent commit that does not change files matching the same mapping.In version 0.0.2, this issue can be reproduced as follows...
With a mapping configuration like this:
path1/file1and uses the [skip ci] message tag. This change is pushed to the repo first and the build is skipped as intended.path2/file2. This change is pushed to the repo after Commit 1 and the setup workflow is triggered with path based filtering. The v0.0.2 path filter currently returns the parameters for bothpath1-parameterANDpath2-parameteras true.In this example with the current logic, this will potentially cause workflows or jobs to run in the continuation config based on
path1-parameterthat were not intended to be run at the time Commit 2 was pushed.