Feature Requests

GitHub Actions support on CircleCI is currently available in open preview on Linux resources. Select your GitHub Actions config during project setup. If you run into issues or have feedback please let us know here.

Ran into the limitation where job groups can't reference other job groups within. Would be nice if this were possible so that de-duplicating jobs could be done more granularly to make pipeline config files more readable.

Currently, if you want to require all concurrent jobs run as the result of a matrix job, you have to list every single one of them out. It'd be much better if there was a built in wildcard capability that allowed you to pin to the config job name rather than having to pin to each unique job name. Otherwise, a wildcard capability for requires could work too. But the first option feels better.

In Github its possible to have many CI config files in one repo, i want this feature for accounts that are using Bitbucket as well

As an admin of orbs (and template configs), I want to have a way to identify whether a failing step / job is coming from orbs or the root config.yml.

URL Orbs are currently enabled org wide and while it is possible to restrict which orbs are used via config policies, going that route does make it hard to tell where an orb is restricted to. Having the ability to select which projects an URL orb can be used in would provide visibility into any restrictions and make this process easier.

Problem Statement: No-op jobs and other non-build job types (like approval and release jobs) prepend the workflow name to the GitHub status check name (e.g., workflow_name/job_name), while regular build jobs display without the workflow prefix (e.g., job_name). This inconsistency creates challenges when: Migrating existing jobs to no-op jobs, as GitHub required status checks must be updated Managing branch protection rules across different job types Maintaining consistent naming conventions across workflows Requested Enhancement: Provide an option to control the naming convention for no-op jobs in GitHub status checks, allowing users to choose between: Current behavior: workflow_name/job_name Consistent behavior: job_name (matching regular build jobs)

There are situations where you would always want a workflow to run, even if a newer build has started. The current implementation of the "auto-cancel redundant builds" feature is all or nothing and doesn't allow granular control of which builds should be canceled. It would be great if the feature allowed for specifying workflows that it would ignore.

For teams that update and distribute jobs used across multiple teams often, it would be helpful if orb supports job groups to reduce configuration maintenance.

Swift can be executed on Linux, so having a convenience image like cimg/swift would be a huge benefit and allow my team to use less costly runners for lightweight Swift package executables.