search

CircleCI-Public / path-filtering-orb

MIT License
24 stars 57 forks source link

Better diffing that includes previous CI runs on the same branch #79

Closed pkyeck closed 1 year ago

pkyeck commented 1 year ago

Describe Request:

Before CircleCI offered the path-filtering/dynamic-config approach of not running all jobs/workflows on every commit, there were others that tried to achieve this as well. I really liked the approach of this repo: https://github.com/labs42io/circleci-monorepo They not only check for changes compared to parent branch but also include previously run builds:

Change detection Each workflow that corresponds to a service is triggered only when there are code changes in the corresponding service directory. Below is a more detailed explanation of how it detects changes:

The first step consists of finding the commit SHA of the changes for which the most recently CircleCI pipeline was triggered Firstly it attempts to get the latest completed CircleCI workflow for current branch (together with the commit SHA) If there are no builds for current branch (which is usually the case with feature branches), it looks for nearest parent branch and gets its commit SHA (using this solution) If there are no builds for parent branch then it uses master Once it has the commit SHA of latest CircleCI workflow, it uses git log to list all changes between the two commits and flag those services for which changes are found in their directories.

Considering this scenario:

1) Monorepo with two services api + ui and main branch 1) setup path-filtering + dynamic config 1) create feature branch 1) make changes to api + ui 1) push to origin + trigger CI 1) CI finds changes in api + ui subfolder and runs both workflows 1) both succeed 1) make changes to one of the services, e.g. api 1) push to origin + trigger CI 1) because path-filtering compares to main branch it triggers both workflows even though ui did not change since the last successful build 😔

I would like to have a parameter for the path-filtering orb with which we could toggle on/off the functionality to also take old builds into account when making the diff.

Are there any drawbacks I'm not considering?

Fernando-Abreu commented 1 year ago

The team doesn't have the bandwidth to work on this, and we a not sure this orb is the best place to enable this feature. If you would like to put this into a canny, our Product will think of a better way to solve this issue