Feature Requests

You are able to see all workflows/jobs for a given branch by going to https://circleci.com/gh/{org}/{project}/tree/{branch} such as https://circleci.com/gh/socialtables/ent-killer/tree/master It would be extremely useful to see a list of all tagged jobs/workflows for all tags. We use tags to trigger staging/production builds and have no way of visualizing a record of all workflows/jobs of this type. Added filtering to be able to get workflows that have done a certain step would also be very useful. For us, viewing all workflows that have succeeded job deploy-production would allow us to fully use Circle to manage deploys. CCI-I-621

We can customize jobs and/or workflows based on pipeleine parameters BUT I cannot see none of those parameters in UI and cannot understand what particular job should do: compile? compile+deploy? compile+test? compile+test+deploy? deploy to instance #1? #2? #3? all of above? And add category "User Interface" to "Ideas" CCI-I-1616

We are using a shared image the cache mount in the dockerfile: ONBUILD RUN --mount=type=cache,target=/var/lib/apt/lists,sharing=locked \ apt update ... This image is then used as the root image in another dockerfile. When this second docker image is build, it fails because of: failed to solve: cannot mount from stage "scratch" to "/var/lib/apt/lists", stage needs to be defined before current command A work around was found by defining FROM scratch as scratch and FROM parent as parent in the child docker image, but this is cumbersome. The build should work just like it does locally.

For jobs, such as machine learning or regression testing, a runtime greater than 5 hours can be required. Having the ability to set the max build runtime greater than 5 hours would be helpful for these use cases.

Currently when we define any command then it only gets executed when the job passes. However, there are mostly chances where we want our command to be executed always no matter the job passed or failed. Can we have by default command execution set to "always"?

Some times there are long parameter names for prepopulated parameters. This causes them to be cut off in the UI for the Run Pipeline modal. Adding a tool tip when hovering over a param name to display the full name would be ideal, but making the field bigger so that you can see the full name of the parameter would be good too

While self-service audit capability by an end-user through the UI is a very nice feature, it would be great to allow for dynamic log shipping or making the audit logs queryable through the REST API , so they can be fed into a Security Incident and Event Management type solution. (or into Splunk, another logging tool, etc) As a fall out of the CircleCI Security incident announced in early January 2023 (rotate secrets), having the ability to quickly diagnose this data and compare it to other data we already had from other systems would have made security triage significantly faster/easier.

Similar to Github Actions: Creates an expandable group in the log. To create a group, use the group command and specify a title. Anything you print to the log between the group and endgroup commands is nested inside an expandable entry in the log. e.g.: echo "::group::{title}" ... echo "::endgroup::"

There should be ability to add metadata about a context, such as description, owner (or user who created; there are two requests for that already), which represent information about the purpose and reason for the context. This is not metadata about the individual environment variables IN the context, but the purpose FOR the context. The user/users who have the ability to modify the context should be able to update this information, as well as the org admins. e.g., "This context helps restrict deployments with sensitive deployment keys for the staging environment"

At the moment each scheduled pipeline is locked to a specific branch, however, with scheduled workflows you could easily set any number of branches for the schedule to run on. To simplify the setup to run across multiple branches, a trigger should support either a list of branches or regex branch matching.