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.
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.