Support new M1 ARM-based Macs
M1 based macs compile software stack 2x as fast (according to customer). More apps & companies are going to start running on M1 too
Support automatic retry of failed builds
It would be great if CircleCI allowed you to configure an automatic retry of a build upon failure. Ideally, you would be able to specify the max number of times you would like it to retry. Taken from: https://discuss.circleci.com/t/support-auto-retrying-of-failed-builds/13332/6 CCI-I-935
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
Rerun failed Parallel Runs
We have parallelism set to 28 to run our tests. If a single parallel run fails, we currently have to rerun the entire job. It would be great to just re-run the parallel run that failed. CCI-I-1329
Hide specific steps in GitHub
The CircleCI steps all show in GitHub presently. If our workflow includes a manual step, though (for example, UAT deployment), this also shows in GitHub and causes the status checks at the bottom of PRs to never go green (they're either red because of a test failure or pending because of these manual steps). If the config allowed not posting specific steps to GitHub, we could ignore the manual parts of the workflow so the PR would go green when the tests pass.
Start Next Job In Sequence Before Current Job Finishes
Sometimes when running jobs sequentially Job B may not require data, like a cache, from Job A, but still needs to be run after Job A's tests. It would help reduce workflow duration if Job A could have a step that triggers Job B to start while Job A finishes any "cleanup" steps, like saving a cache. Alternatively Job B could depend on a step's completion in Job A to start.
Org level Email Notification restrictions
We'd like to be able to enforce one or more domains for email notifications so private org notifications aren't being sent to employees' personal emails. Our GitHub org already enforces this and CircleCI should be adhering to that restriction or allow us to configure the same restriction.
Update GitHub Checks (workflow status) when failed jobs are rerun and passing
Currently, rerunning a failed job so that it passes will update the GitHub status ( job level) but not the GitHub Checks (workflow level). It would be helpful to be able to only rerun a failed job without having to "Rerun Workflow from Failed" , if the job passes, update the GitHub checks.
Always run a job, even when dependent jobs failed
Make it possible to enable the flag. when:always , on a job in a workflow, just like with a run step in a job Be able to run a job regardless of other job statuses. CCI-I-1227