Currently, GitLab organization are created with the following syntax: > cci-* This can be difficult to discern when there are multiple GitLab organizations. This feature request is to introduce the ability to rename the organization.

Sometimes it's handy to upload many small artifact files e.g coverage reports. This runs in serial and is very slow compared to uploading one large file.As an example, my coverage reports are 8mb/400 files. On my last build 36s was spent uploading artifacts out of a total 1:23 for the whole build.See more: https://discuss.circleci.com/t/uploading-artifacts-recursively-is-exceptionally-slow/14558 CCI-I-745

CircleCI Terraform provider would be great addition as it would allow to manage CircleCI projects using code. CCI-I-374

Currently uploading artifacts is really slow if there are lots of files - one way round this is to compress all the individual files into a (e.g.) .tar.gz file, and upload that. Sometimes it is useful to have direct access to the individual files however (e.g. .html files), so this approach doesn't work. If there was a way to un-tar the file after it has been uploaded however this wouldn't be a problem. CCI-I-1146

In some cases environment variables are useful to print out, it would be helpful to be able to whitelist the ones we'd like to show. CCI-I-1223

When using the "Run Pipeline" feature, the name of the parameter is currently left blank, and open to incorrect use. It would be useful to pre-populate this with a list of parameters that have been defined within the config file.

While GitHub controls the branch info and build triggers for all branches, a way to trigger using an alias would prove to be helpful for those working specifically with forked PRs.

The reason is because we build environments based on the workflow and if its fails we are able to destroy servers build as part of the job , but when someone cancels the job we are not able to do the same and we have to manually destroy the env CCI-I-1285

Pure and simple, just like how environment variables can be supplied through contexts at an organisation level. It would be nice to supply 'SSH Permissions' or (ssh keys) at an organisation level This comes in handy when connecting to bastion hosts CCI-I-928

Hi, I belive the following scenario is generic and other people will find it useful. Scenario: A mono repo contains git submodules. These submodules are separate git projects (by definition) with their own .circleci/config.yml files and can built/deployed independently. The host repository (monorepo) should be able to build each submodule as a part of its workflow by continuing with submodule projects circleci config files. It would be nice if we could specify which submodule branch to checkout. My attempt I found Path Filtering and Continuation Orbs can't handle the above scenario due to different reasons. My support request: 141996 confirmed the same. Thank you! Regards, Tharaka Manawardhana