2.0: Need CIRCLE_WORKFLOW_ID env var exposed


Hey friends,

Can you please expose CIRCLE_WORKFLOW_ID as an environment variable in builds? We currently rely on CIRCLE_BUILD_ID to group similar data across containers, but now with the introduction of workflows we need to be able to group data uniquely across the entire workflow, which is hard without a shard unique identifier at the build level.


Expose workflow name as environment variable?

Yes, please. Brian here from Dollar Shave Club.

We had to use workspaces https://circleci.com/docs/2.0/workflows/#using-workspaces-to-share-data-among-jobs as a suboptimal workaround.


Thanks for the feature request. This exists already but is undocumented as we’ve not finalised if it might change in the future. We’re not sure how useful it is, but since a few people have asked, I’ll share this now:

There’s an example here: https://circleci.com/gh/gordonsyme/gordon-test/1272 (expand the “Workflow workspace env vars” step).

Attaching a workspace also prints out info about what’s happening, expand “Attaching Workspace”

One thing to note is that the workspace UUID isn’t enough to work out what content you get. You also need to know the UUIDs of the upstream jobs, those are in another env-var.

If you can give us feedback on if that’s useful and how you make use of it, we can discuss whether to solidify this feature and document it.


I have a very similar use case as @fotinakis.

I’d prefer to have a WORKFLOW_NUM instead of an UUID. Would that be possible?


Thanks for the suggestion. This is definitely something we’re considering. Can you explain how a WORKFLOW_NUM will be helpful compared to the UUID?


We are using BUILD_NUM to tag our docker images. Using numbers feels easier to manage compared to UUIDs. It helps with communication inside a team where we always refer to build using their numbers. We are sort of used to numbers :smile:


+1 that something like WORKFLOW_NUM would be extremely useful (and that not having this is making it a pain to migrate one of my existing CircleCI projects to use workflows). I’m in the same boat as rvignesh89 – we use build numbers to tag our Docker images. Even though they’re not perfect, for a given branch they’re a stable identifier that monotonically increases, so they’re useful to use for that purpose.


I get the sense that there are two things being discussed here. From what I understand, @fotinakis wants to determine which different builds belong to the same workflow. That seems unrelated to the workflow ID being an integer instead of a UUID.

CIRCLE_WORKFLOW_ID is indeed the same for builds from the same workflow, but it seems to change if you “Rerun failed steps”. For that case, I found (experimentally) that CIRCLE_WORKFLOW_WORKSPACE_ID stays the same across the multiple workflows that you get from rerunning failed builds, which makes sense, since they should share the same workspace.

Also, @tom linked to https://circleci.com/gh/gordonsyme/gordon-test/127211 for seeing the CIRCLE_* environment variables, but you can actually also see all exposed environment variables at the end of the output of the “Spin up Environment” step.


@teeberg you are right. Looking back at the original request I realise that the purpose is different.

I’ll create another thread for WORKFLOW_ID as an integer as I don’t see one for that.


+1 we need to look up info about the previous build artifacts


Also, a CIRCLE_WORKFLOW_URL would be useful. My use case is that I have a step that requires manual approval, and I’d like to take the user straight to the workflows page (the one with the graphically linked steps).


I don’t see another issue for WORKFLOW_ID as an integer, so I’ll just pile on here.

We would also like to see a WORKFLOW_NUM as an integer, as we currently use CIRCLE_BUILD_NUM to name test fixtures. Simple monotonically increasing integers are easier to manage (and clean up) than longer UUIDs.


Any update on this feature request?

It’s a pretty basic request so that we can tag application builds with a incremental number rather than the current workflow ID that looks like 93cee048-ca26-4a10-801b-76604acbce44

It’s would be easier to look at the builds and say, this one has been built after this one, etc…


I have also just run into this. WORKFLOW_NUM would be a much more useful for image tagging.



For Android builds we add the build num as the latest part of the build number and it only accepts numbers, so I can’t use CIRCLE_WORKFLOW_ID. As we have a workflow it’s strange to have multiple APKs generated with different build numbers when all of them were based on the same commit.



Also the example from above no longer exists


Where does this stand? We are waiting for something like incremental workflow numbers.

Who can tell which build is newer from this???