Whitelisted IPs 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
Allow multiple filters together AND/OR
Made in response to this discuss post: https://discuss.circleci.com/t/circle-2-0-workflow-filters-should-be-logical-and-not-or/18231 These two filters should logically AND meaning both must be true to execute. This currently accepts either as a valid option, a logical OR. - deploy_production: requires: - build_and_push filters: tags: only: /^v\d+.\d+.\d+$/ branches: only: /^release$/ CCI-I-869
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
Tag/Branch filters should be AND, not OR
Filters should allow for tags with branches not one or the other. It seems a pretty common use case to want only a branch to build but not run a deploy workflow unless branch:v1.0 tag has been added/approved/merged etc. CCI-I-305
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
Allow branch whitelist to override “Only build pull requests”
This is mostly copied from a thread in the Community Forum here - https://discuss.circleci.com/t/allow-branch-whitelist-to-override-only-build-pull-requests/6392 The goal is to be able to have Circle automatically build all commits to the default branch as well as other specially named branches without having to build non-PR branches. This is very useful for those of us who have expensive steps in our build process (like tests that run on external servers, or those using the mac OS builds who want to save minutes). Minimum viable here would be to allow a list of branch names. Better would be to allow a list of branch names and/or regexes to specify branches. We have a work-around that we developed locally by opening up fake PRs from our release branches into master as part of our process. But it's manual, error prone, and inelegant. Supporting a whitelist would be much nicer. CCI-I-215
Configure Docker Hub user/pass
Now that Docker Hub is introducing rate limiting, it would be great if you could set a docker hub user/pass from an org level. So that each project doesn't need to add a "auth" to their circleci docker config.
Ability to view all re-run jobs for a project in the new UI
It would be great to have a user friendly way to view all re-run jobs in the UI. Current workaround: It is not currently possible to view jobs that have been re-run. As a workaround, you can use the legacy jobs view by adding jobs to the end of a projects URL. https://app.circleci.com/pipelines/github/adeo/PROJECT_NAME/jobs/ This is not user friendly.