Allow configuration of shorter maximum job runtime
Allow the user to configure a job to cancel itself and/or the workflow at an upper time limit that the user sets, within the 2/5 hour limit of Cloud jobs. This would prevent wasted time and credit consumption when a build is taking unnecessarily long times to complete a job, when inevitably it will fail or is taking an abnormal amount of time.
Support ARM resource class on Docker executor
Some customers that are building for multiple architectures would like the ability to build both AMD and ARM images on Docker executors.
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
Filter Jobs based on Calendar Dates and/or Times
I really like the new feature that allowed filtering on jobs based on days greater than, but I commonly find myself wanting to filter on jobs from a specific date and/or time, and a date and/or time range. Maybe we can keep this new dropdown and its functionality, yet move the calendar icon away from it and have a button with the calendar icon next to (right after) that allowed to to select a calendar date or range along with time filter . .. Examples: 1.) Selecting: [01/01/2023] 2.) Selecting: [01/01/2023-01/01/2023] 3.) Selecting: [01/26/2023-01/26/2023] (00:00 - 13:47) I feel this new feature would be extremely helpful and useful. Thanks!
Generate jobs from map of parameters
I have a scenario where I need to run a single job multiple times with varying parameters. In an effort to reduce duplication I looked to use the matrix feature but as it generates the product of the parameter lists I ended up with far more jobs than needed and the number of exclusions required would be too complex to maintain. It would be good to be able to generate jobs from a map of parameters where a job is created for every key of the map. Essentially like a foreach where the set of parameters from each element create a different job configuration.
Ability to disable in-app config editore
Currently, the In-app config editor is enabled by default. It would be useful to be able to disable this feature on an organization level.
Increase the max size of Config
3MB for a compiled config file is very limiting. For example if we use aws-eks/update-kubeconfig-with-authenticator 42 times in different jobs and when it gets compiled it becomes about 9000 lines. Which takes up quite a lot of 3MB limit. Is there possibility in increasing the limit or exclude the orbs compiled lines?
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
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
Auto-cancel builds for default branch
Originally asked here: https://discuss.circleci.com/t/auto-cancel-builds-on-default-branch/5536 We would like auto-cancel to apply to the default branch, specifically because we have a deploy action associated with it. The deploy is slow and multiple builds are often racing with each other and we occasionally get an older build that finishes after a newer one, leaving us with older code deployed. (This is only for a staging environment deploy in our case though.) CCI-I-214