Check for scheduled jobs in config when adding a project
Right now it seems workflow schedules are only checked and scheduled when a pipeline is triggered. There are occasions when it would be helpful to check for schedules when adding a project as well. Such as when users need to remove and add a project for troubleshooting. It's more intuitive for CircleCI to see the project has an existing schedule, and to run it. Rather than the user having to trigger a pipeline.
[UX/UI] Filter by workflow
Currently it is possible to view jobs and workflows by branch but you can not specify further to show individual workflows. Users with multiple workflows may have trouble finding certain jobs that run less often when there may be many commits being made.An example would be a project (on any branch) with a workflow that runs per-commit and a secondary workflow that runs once per week. There would currently be no way to exclusively view the scheduled weekly workflow. CCI-I-757
Filters on pipelines pages
In our new UI, we no longer have workflow/jobs pages - so we've modified this idea to apply to the pipelines page.It would be helpful to have some basic filtering on both pages to search for past builds. Workflow page:- Build status (Failed, Success, Running)- Build type (Commit, Triggered/Cron)- Workflow name Jobs page:- Build status (Failed, Success, Running)- Build type (Commit, Triggered/Cron)- Workflow name- Workflow step CCI-I-495
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
Ability to specify which environment variables are masked by Secret Masking
In some cases environment variables are useful to print out, it would be helpful to be able to whitelist the ones we'd like to show. CCI-I-1223
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
Auto-cancel redundant builds using "when" clause matches
If a workflow is triggered using the when clause, cancel this build when another workflow is triggered that contains the same when clause and matches.
Per Branch Parallelism and Kill Redundant Limits
On our master branch we have a pipeline that we want to test each commit, but because of external resources used as part of the integration test suite we can only run one job at a time. This means we have to have a merge master who is only merging one job, waiting for it to finish and then merging another job. It would be great to be able to set the parallelism allowed on that branch to 1 WITHOUT having to turn off Kill Redundant Builds, which we want on PR branches. Similarly, we have branches for deployment to various environments based on merge to a branch. Killing a redundant build there can screw up the deployment, so a release manager has to merge to that branch and then wait for it to finish. As a last step on that job we push a commit to the release branch with the version, which triggers a new build, which creates a race condition for killing the redundant build. We are happy to have it spin up another job and we can cancel that build based on the author of the commit, but not being able to limit parallelism and prevent killing redundant means we cannot push the version commit when we make it we have to do it as the VERY last step and hope the deploy job doesn't get killed by redundant.
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
Disable "Rerun workflow" buttons while workflow is enqueued
Sometimes it takes several seconds for a new workflow to be enqueued after the "Rerun workflow from start" or "Rerun workflow from failed" buttons are clicked on the Pipelines page. Sometimes when the new workflow is not enqueued immediately I click these buttons again thinking that the first click was not registered. This ends up enqueueing two workflows. These buttons should be disabled while a new workflow is enqueued after the first click and maybe show a loading animation to indicate that a new workflow is being enqueued.