Link to build or at least tag

It would be great if there was a view and a link for a build, or at least for each tag. The builds are separated by horizontal lines on the dashboard, but we can only link to a workflow run or a job run or a branch, etc. It would be helpful to me to always use a link to the whole build, with all the workflows in it. Feature branches work well because there’s a link for a branch. It was working well for me when I had a separate branch for each release, but now we have a tag for each release, so we can only link to one workflow or one job. It’s even hard to get from the workflow view to see the full build.


Hi @nroose,

Thank you for sharing your feedback with us!

In addition to linking to a specific workflow or job, it is now possible to also link to a specific pipeline as well. The url takes the following format:

Here is an example using one of our public projects:

This will show you all of the workflows/jobs for the pipeline number 953.

You can get the pipeline number by referencing the url for workflows/jobs. It is also available on the pipelines list page as well.

As for tags, we are tracking this as a feature request for which you can add any additional comments or feedback on the following page:

Need view to see all Jobs/Workflows for a tag | Cloud Feature Requests | CircleCI Ideas

Please let me know if you have any additional questions as well!

Is there a way to get that pipline id or url from inside a job so that I the job can post it to slack? Perhaps a built in environment variable? Thanks! Sorry for the delay.

Hi @nroose,

This can be done by getting the workflow id from the environment variable CIRCLE_WORKFLOW_ID and passing that to the following API endpoint:

Sample api call using curl:

PIPELINE_NUMBER=$(curl --request GET \
--url '' \
--header "circle-token: $CIRCLECI_TOKEN" | jq '.pipeline_number')

The pipeline number will be returned. Here is an example json response:

  "pipeline_id" : "1ac1943v-a2f5-4fe1-82ff-f39d899vscf5a",
  "id" : "b8b116f6-911c-4g1c-bf17-0fd4gbde7c12",
  "name" : "build_and_test",
  "project_slug" : "gh/test-org/test-project",
  "status" : "failed",
  "started_by" : "2191g76e-87df-3v32-a4adv-371e649sdfg8",
  "pipeline_number" : 1276,
  "created_at" : "2022-07-16T18:18:20Z",
  "stopped_at" : "2022-07-16T18:22:21Z"

After getting the pipeline number, you could construct a url using the envars CIRCLE_PROJECT_REPONAME and CIRCLE_PROJECT_USERNAME, or just hard coding the project url part.

I have had a few hours of just a lot of nothing. That curl command above got me a “Workflow not found” message. I used the same path in the browser, and got the right json. I am not sure which token that token you are using is, but I tried project api tokens with each of the different permissions. All of them got “Workflow not found”. And I searched and read a lot of docs about all the different auth and all the different api versions and I have no idea which one is up to date, but I didn’t have any luck with any of them. It also just seems really silly to use a circleci api from a circleci workflow to get the pipeline number. Why not just put that in some env variable? I want to put it in a slack message, and I think maybe if I get that api working, I can get the slack step working, but probably not the slack job, which I don’t think supports calling curl in the fields. And you are not actually linking think pipeline number in the UI where you are putting the pipeline number…

Also, in general, it would be much better to be able to search for the tag and/or sha in the list. We use tags to do releases. We don’t have the ability to find the full set of workflows for a tag like we would for a branch. If you will never do this, I guess we should switch to using branches.

I can answer the issue regarding the type of token. For API v2 you need to use a personal API token, not a project token. The detail can be found at

(and yes the doc team could improve the layout to help everyone out - even having the URLs and titles match the exact name of the documented item would help).

In terms of the placing of the pipeline number into an environment variable. I can only speculate, but with the way things seem to work, I think the pipeline number is unknown at the time the variables are defined. So what is really needed is a set of commands in the script language to return such values at run time.

That sucks. Really don’t want to do that. Always get bitten in the ass when I do that. Really really really we want real handling of tags like branches. I guess we will consider using branches. It just causes such a mess.

Have you decided to ignore this bug?