I think this is a bug with the Bitbucket API.
I triggered a pipeline build with a curl like:
curl \
-X POST \
-s \
--fail-with-body \
--user blah:blah \
-H 'Content-Type: application/json' \
https://api.bitbucket.org/2.0/repositories/blah/some-project/pipelines/ \
-d '{...}'
...and it triggered fine. The response includes this fragment:
"links": {
"self": {
"href": "https://bitbucket-pipelines.prod.public.atl-paas.net//rest/1.0/accounts/zzzz897f-cf32-4b66-825f-5123a9665fab}/repositories/zzzzf159-d03c-4508-a9cb-fa5a922e7e07}/pipelines/zzzz4283-b506-43eb-a8b5-376806f99be6}"
},
"steps": {
"href": "https://bitbucket-pipelines.prod.public.atl-paas.net//rest/1.0/accounts/zzzz897f-cf32-4b66-825f-5123a9665fab}/repositories/zzzzf159-d03c-4508-a9cb-fa5a922e7e07}/pipelines/zzzz4283-b506-43eb-a8b5-376806f99be6}/steps"
}
}
...but when I tried to GET either of those URLs, I get a 404. When I remove the double slash at the end of the hostname (`paas.net//rest`), then I get a better response. I actually get a 401, but that probably is something I'm doing wrong.
The point is that the server probably has a trailing slash configured on the prefix that is prepended to the rest of the URL that's returned to the caller.
Hi Tom,
This is indeed a bug, the urls that are returned are internal urls and cannot be used to retrieve the pipeline or the steps.
We have a bug report about this in our issue tracker:
https://jira.atlassian.com/browse/BCLOUD-21062
The way to work around this at the moment would be to manually assemble the url instead of using the ones in the response
https://api.bitbucket.org/2.0/repositories/{workspace}/{repo_slug}/pipelines/{pipeline_uuid}
https://api.bitbucket.org/2.0/repositories/{workspace}/{repo_slug}/pipelines/{pipeline_uuid}/steps/
Kind regards,
Theodora
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.