Monorepo Support and/or 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/ CCI-I-208
IP Allow List for builds
Customers are requesting an ability to see the exact list of IPs that CircleCI webhooks and SSH connections come from. CCI-I-35
Trigger new build when a Pull Request is opened
Circle CI should generate a new build when a pull request is opened on github. The current implementation uses the branch's most recent commit result, instead of generating a brand new build. Consider the following situation. 1) An engineer creates a branch within github, and pushes code up at their leisure. Circle CI builds the project on each commit. 2) When it comes time to make a pull request, the engineer opens up a PR on github, without creating a new git commit. This workflow does not seem to trigger a new build of the branch on Circle CI, and instead Circle CI uses the build result of the most recent commit as the build status of the Pull Request. This seems to be an obvious workflow flaw given that I may have additional logic to build a PR artifact for testing purposes, vs the normal branch commit process. This has been discussed both here and here on your forums as well. I have found 2 additional configurations under "advanced settings" that compliment this idea, but do not do what I intend.• Build forked pull requests• Only build pull requests As a counterpoint, you can configure both Jenkins and Travis CI to do this, so this seems like a pretty straightforward use case of the platform. Obviously, if you if you push an additional commit to the branch that already has an existing PR, the additional variables or logic within Circle CI will be present. CCI-I-316
Red/Green color blind friendly design
The Workflows results page (perhaps as well as other pages) could differentiate between passing and failing jobs more clearly as users with red/green colorblindness may have difficulty picking out a failed red job from a list of green ones. CCI-I-803
Limit SSH Access To Admins
Enable a setting to restrict the "Rebuild with SSH" action to only administrators (role on Github Team) CCI-I-823
Make it possible to sort contexts
In the UI, I'd love to be able to sort contexts by name or creation date.
Support regex in conditional statements
At the moment we can do the following: workflows: my-workflow: when: condition: or: - equal: [ dev, << pipeline.git.branch >> ] However I would like the ability to use regex on the matching similar to how you can use regex in tag filters at the workflow level.
Option to allow failures in Fan-In/Out Workflow
The requires tag in workflows really limits what is possible. Requires makes a lot of sense for the deployment scenario used to demo it, but waiting for a group of jobs to complete (pass or fail) should be an option. Scenario: Setup -> Run multiple sets of tests in parallel -> Combine test results/coverage results/artifacts and report to PR That scenario above isn’t possible because if a single test fails in any of the jobs running in parallel the the fan-in step won’t run. CCI-I-344
Support auto-scaling for self-hosted runners
Automatic scaling to handle changing workloads - AWS ASGs, Kubernetes, etc.
Offer co-located Maven repository
You could drastically improve the CI build experience for the Java ecosystem if you offered a Maven repository mirror of Maven Central that was co-located with the CircleCI build hosts. It would significantly cut down on bandwidth between Maven Central and the CircleCI infrastructure, and builds that used the local mirror would run an order of magnitude faster if they were pulling the gigabytes of dependencies over a local connection instead of over the open Internet.