Submit Your Ideas

We want to hear from you - vote for the features and improvements you'd most like to see, or submit your own ideas if you don't find them already listed.

Support filtering based on VCS changes in a specific directory

Currently, any merges to master trigger all steps of all workflows. In an monorepo that houses multiple projects, this results in multiple redundant steps as, for example, the backend is re-tested and re-deployed even if only frontend changes have been made.

 

It is currently possible to do:

 

workflows:
flow:
jobs:
- deploy:
filters:
branches:
only:
- master

 

It would be useful for all teams that run a monorepo to also be able to specify, say:

 

workflows:
flow:
jobs:
- terraform:
filters:
modified_paths:
only:
- /^infrastructure/
- deploy:
requires: terraform
filters:
modified_paths:
only:
- /^app/
  • Avatar32.5fb70cce7410889e661286fd7f1897de Guest
  • Feb 4 2018
  • Planned
  • Attach files
  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    07 Feb 06:49

    This feature is need for a organisation which has monorepo consists of multiple micro services as folder to avoid multiple repository overhead. 

    I am in need of this in my case i have a repo which consists of 5 micro service any changes made on single micro service triggers build for whole system which is more inefficient in this case.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    28 Feb 19:35

    This is also required for us, with a very large monorepo.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    03 Apr 08:24

    I have a similar use case and this would indeed help me very much. I started working on a custom script to hack this feature, you can see the diff here:

    https://github.com/decidim/decidim/pull/2028

    But if this feature was built-in it'd be super-awesome!

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    16 Jul 12:37

    This would be a great feature, because we have on big mono-repo with a workflow containing of 37 jobs.
    We have added a custom bash script which checks which files changed within a commit (or diff from master).
    But still all jobs are being queued and we can only check within the job itself - which means that image download and restoring of the cache are run in any case (means severals second - up to minutes a worker is blocked with nonsense work)

    Maybe it would be even better to be able to set a script (bash command or similar) as filter. Depending on the exit code the job will be queued.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    13 Aug 19:33

    This is definitely necessary, lots of people use monorepos, including well-established authorities like Babel, Google, etc.

  • Admin
    Nathan Dintenfass commented
    13 Aug 22:46

    Something like what you are proposing is under design -- we are working out a few details like what to do when receiving an API call directly to a branch rather than a webhook that has a commit -- the latter has a fairly clear set of changes, but the former is somewhat more ambiguous about what "changed" (should it be from previous build vs. previous commit, for instance). We do hope to work on this once we clear out our current backlog, though, but we can't yet predict timing of release.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    20 Aug 09:37

    This is is something that we'd benefit from as well. We'd probably get it to work with only regex on paths but my hunch is that it would be useful to be able to have a pre-process script that would deliver a list of jobs that should run (or something like that). We currently have at least jobs that should run if either path A or path B have changed.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    25 Aug 22:43

    Yarrrrr! This would be lovely! Please oh please!

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    01 Sep 00:06

    This would be a truly needed feature... We're just about to start migrating to CircleCI - and this would save us...

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    29 Sep 18:24

    Just catching up on the features here and am pleased to see this is planned. Is there any estimate on the release of this feature?

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    14 Nov 14:30

    An absolute must in a modern JS monorepo setup.... upvote :)

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    26 Nov 21:37

    How far out is this planned feature?  I'm evaluating tools for our Monorepo and trying to see how this would impact things.