* Detect commit hashes from merge_group event
* Apply suggestion from @masaru-iritani
Co-authored-by: Masaru Iritani <25241373+masaru-iritani@users.noreply.github.com>
* refactor: update PullRequest type usage in getChangedFilesFromApi and related functions
* Run `npm run pack`
---------
Co-authored-by: Sascha Bratton <sascha@brattonbratton.com>
Setting the new 'predicate-quantifier' configuration parameter to 'every'
makes it so that all the patterns have to match a file for it to be
considered changed.
This can be leveraged to ensure that you only build & test software changes
that have real impact on the behavior of the code, e.g. you can set up your
build to run when Typescript/Rust/etc. files are changed but markdown
changes in the diff will be ignored and you consume less resources to build.
The default behavior does not change by the introduction of this feature
so upgrading can be done safely knowing that existing workflows will not
break.
Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
git show-ref will return all branches where end segment matches the input. This cause issues when there are both 'someBranch' and 'somePrefix/someBranch' branches. This fix ensures the correct ref is returned by explicitly matching segments after common parts (e.g. refs/heads).
the number returned by pullRequest.changed_files doesn't reflect the correct number of real changed files. Therefore lot of filters didn't work in my scenario, as it said nothing has changed. This especially happens if there are more than 100 files changed (first time I experienced it where over 1000 files have changed, and now when there were about 300 files that have changed).
I changed the detection by querying the api as long as it returns new results. This ensures all pages have been retrieved. It's tested and used in production on our end, but please check again if I didn't miss anything.
Thanks a lot for this awesome github action :)
Michal Dorner