Feature Requests

This idea is about https://circleci.com/docs/2.0/artifacts/ (source file: https://github.com/circleci/circleci-docs/blob/master/jekyll/_cci2/artifacts.md ) I am building a multi-module project. I have artifacts that I want to store that follow this pattern: " /build/reports" where would be "module1", "module2", etc. Could the store_artifacts path allow a regex to support that? Or is there any other way to shorten the syntax so I don't have to repeatedly specify multiple lines to store artifacts from all modules? Thanks for considering. CCI-I-282

In the legacy UI there was a "Queue" tab showing a list of builds behind which a given job was queued. Would it be possible to access that same information in the current UI. This would be useful for customers who reach their concurrency limit and need to identify the jobs involved in the queueing.

We rarely have any concurrency in our jobs and downloading the DLC every time is much slower than a volume-mounted DLC. Please revert or add a config to get the old behavior back. Thanks!

Reference stackoverflow post: https://stackoverflow.com/questions/49659880/circleci-v2-config-how-do-we-filter-by-owner-in-a-workflow Details: In the circleci version 1 config, there was the option to specify owner as an option in a deployment. An example from the circleci docs ( https://circleci.com/docs/1.0/configuration/ ) with owner: circleci being the key line: deployment: master: branch: master owner: circleci commands: - ./deploy_master.sh In version 2 of the config, there is the ability to use filters and tags to specify which branches are built, but I have yet to find (in the docs, or on the interwebs) anything that gives me the same capability. What I'm trying to achieve is run build and test steps on forks, but only run the deploy steps if the repository owner is the main repo. Quite often people fork using the same branch name - in this case master - so having a build fail due to an inability to deploy is counter-intuitive, especially as I would like to use a protected branch in git and only merge commits based on a successful build in a pull request. I realise we could move to only running builds based on tags being present, but nothing is stopping somebody with a fork also creating a tag in their fork, which puts us back at square one. This capability of v1 configs is missing in v2 workflows. Putting in a bunch of if statements in the workflow commands is messy, and while it will do as a workaround, it would be good to have the capability in the v2 config in a cleaner/easier to understand way. An example from the version 2 config document ( https://circleci.com/docs/2.0/workflows/ ). workflows: version: 2 un-tagged-build: jobs: - build: filters: tags: ignore: /^v.*/ tagged-build: jobs: - build: filters: branches: ignore: /.*/ tags: only: /^v.*/ CCI-I-356

In CircleCI 1.0 you could do this by adding commands to the .circlerc file. This was great - because it was driven by CirclCI itself and didn't rely on shell specific tricks (e.g. like $BASH_ENV). In CircleCI 2.0 this capability is not present and there is currently no way to do this for the official Alpine docker images. You have to include your step(s) in every single run command. We have large modular build and deploy scripts with many run commands and having this capability keep things simple and follows DRY principals. It's also a very flexible feature People can easily carry environment variables across step (or even set them from within a step and have them available to other steps) You can setup you shell the way you need to before each run step More detail here: https://discuss.circleci.com/t/circlerc-bash-env-env/25011/4 CCI-I-600

When there's a problem (e.g. github hooks etc) and things aren't showing up in circleci, currently I use the status/health indicator before searching elsewhere. Need to have this in new ui CCI-I-1396