Feature Requests

At the moment, dynamic configs are very helpful for isolating and running a specific subset of a configuration file. However, when it comes to checks, and reporting if a workflow or job passed, it can sometimes lead to PR's not being able to be merged since specific items were not executed. There should be a way to support checks with using the dynamic config feature.

The current error "Pipeline is not in setup state" does not tell the user that this workflow cannot be re-run, which can cause the user to try to re-run from failed (or other re-run types) multiple times. Please update the error message to provide instruction to prevent unnecessary troubleshooting.

Hi there, How can I Skip one out of multiple Jobs, I understand there is [ci skip] but this will skip the entire jobs. I want a situation where I can only skip TEST out of Compile, TEST, BUILD jobs. Is this possible, if yes How?

I think we should take the matrix feature one step forward. Instead of explicitly defining the matrix values, it would be great if we can derive the values from pipeline parameters. I see two ways of achieving it: read values from comma delimited value of existing string type parameter, or introduce a new "list" type parameter.

When setting up a new project, offer the option to enable Dynamic Configuration, or auto-detect a setup a setup workflow upon checking for config.yml and offer the option to enable at that time. This would particularly be useful when setting up a forked project where the upstream project already uses Dynamic Configuration.

The ability to configure triggers via API was recently released - https://circleci.com/docs/api/v2/#operation/createSchedule but it's not possible to specify a different config, it just assumes my scheduled/triggered workflows reside in .config.yml?

We are fairly limited in the data that we can pass to a workflow when triggering via the API because pipeline parameters have to be declared in config.yml using primitive types. This make is difficult to send an object to be decoded in a library during one of the steps. For instance, we currently have to send a comma-delimited string for one of our parameters. We're also exploring the need to send an entire object from a local "build creator" app to the workflow as an existing string will no longer suffice. Being able to pass a JSON payload that could be accessed in an environment variable rather than rendered in the config.yml file would be a huge improvement and would bring this on par with GitHub Action event triggers.