I was able to achieve this by using Dynamic config.

Just that I had to duplicate the params in config.yml and baseConfig.yml

I'd be passing different values for params and the name would reflect accordingly in the workflow name

baseConfig.yml

---------------

version: 2.1

parameters:

ENV:

type: enum

default: ""

enum: ["","dev", "stg","prod"]

PRODUCT:

type: enum

default: ""

enum: ["","productA", "productB"]

orbs:

aws-s3: circleci/aws-s3@3.0.0

workflows:

version: 2

lint:

unless: << pipeline.parameters.ENV >>

jobs:

- lint

test_<env>_<product>:

when: << pipeline.parameters.ENV >>

jobs:

- test

....

.....

config.yml:

version: 2.1

setup: true

orbs:

continuation: circleci/continuation@0.1.2

parameters:

ENV:

type: enum

default: ""

enum: ["","dev", "stg","prod"]

PRODUCT:

type: enum

default: ""

enum: ["","productA", "productB"]

jobs:

setup:

executor: continuation/default

steps:

- checkout # checkout code

- run: # run a command

name: Generate config

command: |

sed -e 's/<env>/<< pipeline.parameters.ENV >>/g;s/<product>/<< pipeline.parameters.PRODUCT >>/g' .circleci/baseConfig.yml > .circleci/generatedConfig.yml

- continuation/continue:

configuration_path: .circleci/generatedConfig.yml # use newly generated config to continue

workflows:

setup:

jobs:

- setup

Voicing support for this idea. It would be nice to be able to parameterize the name of a workflow, or even a job. This will make it much easier to identify characteristics about the job without having to drill down into the steps.

Would be very useful to be able to use a pipeline parameter in the workflow name. For example we have a common deploy workflow that takes a pipeline parameter to tell it which environment to deploy to. It would be really useful to have that workflow named as deploy-<env> in the UI

I would really really like this feature very much. We have workflows that we would like to identify with version. We don't do tag based deployments. Rather our code generates a semantic version automatically. It really makes it easy to identify things instead looking at commit ids or messages.Maybe an ability to add custom information in UI, something like. Eg: <branch-name> / <workflow> / <custom info>Eg: master/workflow/1.1.2Don't know how much this is possible, as it seems that we have to checkout code ourselves as part of jobs. And to do something like that, you will either have to write code in yaml (which still wouldn't let you be that dynamic) or checkout code automatically and have hooks. And using API is not the answer.

Same as https://ideas.circleci.com/ideas/CCI-I-630?

I have this problem when submitting jobs via the API. The job only has the branch name, and often multiple jobs are submitted against the same branch (master) for different purposes. It's impossible to tell them apart from the UI.