Config

For many reasons, it is necessary to determine the branch target pull request that triggered the current workflow. This has been a frequently requested feature, and has cropped up on the discuss.circleci site in numinous requests and formats. Example: Conditioning the selected image tag used by the docker executor via base branch name from PR, given that this is otherwise intractable given the otherwise lack of propagating such conditional logic to a jobs executed prior to the job being able to even run.Please see the reference here: https://discuss.circleci.com/t/conditioning-docker-image-via-base-branch-name-from-pr/28426 Issue: Currently, as of CircleCi 2.0, no environment variables provide a basic means to aquise the branch name targeted by a pull request, be it from a forked repository or internal from the local repo. https://circleci.com/docs/2.0/env-vars/ The closest contenders include the CIRCLECI_BRANCH that for pull requests, instead returns the name of branch intended to be merged from with the new commits, not the base branch for which the commits would like to be merged into. Additionally, CIRCLE_PULL_REQUEST only contains the URL of the associated pull request, which has no-or-limited utility for the case example described above, given the branch name would first need to be parsed from the URL before useable. Alternatives: If we take a comparative look at Travis, provided is the TRAVIS_BRANCH env variable that returns the the branch targeted by the pull request if triggered by such a PR. https://docs.travis-ci.com/user/environment-variables/ TRAVIS_BRANCH: for push builds, or builds not triggered by a pull request, this is the name of the branch. for builds triggered by a pull request this is the name of the branch targeted by the pull request. for builds triggered by a tag, this is the same as the name of the tag (TRAVIS_TAG). Proposal: Given the current pattern of available variables from CircleCI, including: CIRCLE_PR_NUMBER Integer The number of the associated GitHub or Bitbucket pull request. Only available on forked PRs. CIRCLE_PR_REPONAME String The name of the GitHub or Bitbucket repository where the pull request was created. Only available on forked PRs. CIRCLE_PR_USERNAME String The GitHub or Bitbucket username of the user who created the pull request. Only available on forked PRs. I'd suggest adding CIRCLE_PR_BRANCH that provides such a feature as follows: CIRCLE_PR_BRANCH String The target branch name in the GitHub or Bitbucket repository where the pull request was created. Only available on forked PRs. Alternatively, it might be nice to follow the logical switching of TRAVIS_BRANCH to allow for in branch commits to use the same conditioning logic as described in the case example link without compilation then the job trigger does not arise from a PR. CCI-I-894

If the step fails, allow the subsequent steps in job to continue. If the attach_workspace step fails, do not mark the job as failed.

It is today only possible to declare a resource class for the main container. I would like the same capability but for the other containers as well. We have one container that requires more than 2GB of RAM and we can't use it this way. We have to start a remote docker which takes a lot of time to spin up.

We would like to be able to restrict the triggering of pipelines to specific users on specific branches.

At the moment the Cirlce CI config is loaded from the current branch. A feature branch can be changed by a single developer. In order to provide more protection for the Circle CI config, it would be nice if it could be configured for a project to take the Circle CI config from a protected branch. So this branch could be protected by branch protection rules. For example one could configure the main branch as the source of Circle CI config for all the workflow runs of the project, so any workflow run triggered for the Circle CI project would take the configuration from the main branch, independently from the currently built branch. This would enable higher level of protection of the CI config, since one could configure different branch protection rules for this special branch; including requirements like: changes only via PRs, PRs can be merged only with a specific number of approvals and no force pushes. This would make it possible to protect the CI configuration from a single compromised developer account. Thus enabling higher security standards, which is not available currently.

Customer's full PR was ignored because the last commit included [skip ci]. I know this is stated in our documentation. They'd like to see all other commits to build and only ignore the single [skip ci] one. CCI-I-152

Currently when you click on an approval step in a workflow you get a standard modal dialog that does not tell you which step you clicked on. Since we have multiple parallel approval steps this makes it impossible to see if you clicked the right step or mis-clicked and might be approving the wrong thing. At a minimum I would think the dialog should show the name of the step that you are approving. It would also be very nice if you can add a description for the step in config.yml which will be shown in that dialog. This can have important information for users related to automatic deployments. CCI-I-567

Currently, to allow a job to run for a workflow, the user must define a tag filter for each job. With the release of conditional logic, it becomes possible to only compile a workflow with the << pipeline.git.tag >> parameter. However, a workflow will be created with no jobs if the filters are not present. Two potential options would be to allow a workflow level tag filter parameter, or a boolean to run all jobs on tags.

It would be useful to allow "empty" (need a better name) workflow steps with the following properties: can take part in dependency chains, i.e. can require other jobs to complete can be required by other jobs to complete no build steps and require no build agent to run (similar to "approval" jobs) Such jobs could be useful in structuring and organising workflows.They would save repetition allowing cleaner, DRYer workflow codeand the diagrams would be more unserstandable.For example, imagine the following scenario: 3 build steps which run in parallel when all 3 succeed, you want 3 deploy steps to run in parallel Currently you'd do it like this: workflows: version: 2.1 build_then_deploy: jobs: - build1 - build2 - build3 - deploy1: requires: - build1 - build2 - build3 - deploy2: requires: - build1 - build2 - build3 - deploy3: requires: - build1 - build2 - build3 The resultant, confusing diagram would look like this: build1 --+-- deploy1 |build2 --+-- deploy2 |build3 --+-- deploy3 Adding an "empty" job would allow you to refactor, like this: workflows: version: 2.1 build_then_deploy: jobs: - build1 - build2 - build3 - builds_completed: type: empty requires: - build1 - build2 - build3 - deploy1: requires: - builds_completed - deploy2: requires: - builds_completed - deploy3: requires: - builds_completed The code is more natural to read and the diagram would be less confusing: build1 --+ +-- deploy1 | |build2 --+-- builds_completed --+-- deploy2 | |build3 --+ +-- deploy3 CCI-I-855

Since Dec 2021, the default resource class is set to Large for new projects. For organizations, it would be great to be able to set a default resource class (e.g., medium ) at the project or organization level.