Hi,
Prior to this week, our open-source project’s artifacts URLs were in the format of:
https://154279-33258973-gh.circle-artifacts.com/0/build/dist/<build>.tar.gz
As of Tuesday, it seems that the URLs are now showing up as:
https://dl.circleci.com/private/output/job/6bafe8aa-0eb8-4982-a327-3dacdc215644/artifacts/0/build/dist/<build>.tar.gz
The new URL appears to be private and requires a CI token to access. Is there any way we can tell what changed or how to revert this back?
Thanks
Hi @powersj,
Sorry to hear you are running into this issue, and thank you for bringing it to our attention.
I have reverted the changes to your organization. Could you please trigger a new build and let me know if the artifact links point to gh.circle-artifacts.com?
If you would like, we can also discuss this further via a support ticket:
https://support.circleci.com/hc/en-us/requests/new
Best Regards
Hi @powersj
I’m having the same issue with this public project https://app.circleci.com/pipelines/github/orange-cloudfoundry/osb-cmdb where artifact download urls returned by api/v1.1/project/github/orange-cloudfoundry/osb-cmdb/latest/artifacts?filter=successful&branch=fix-issue-166-x-api-info-location are now in the form of https://dl.circleci.com/private/output/job/adec4c77-355d-4d1e-a942-b744ce76e1ed/artifacts/0/artefacts/osb-cmdb-1.7.0.jar and require a token to be accessed.
Is there an option on circleci side to publish back the artifacts ?
Thank you for the prompt response @aaronclark!
I will file a support ticket to follow up on what changed to understand if it was something we did to avoid it in the future.
Thanks again!
We have been hit by this too, but for a private repo.
Specifically, the https://dl.circleci.com/private/output/job/... endpoints do not support the circle-token query parameter, unlike the previous https://*-gh.circle-artifacts.com/... endpoints. Switching to the Circle-Token header works around the problem.
We had the same issue and updating to use headers fixed the issue.
That said, there’s another issue that seems to be affecting us. When downloading a .html file, there’s a 307 redirect occurring… which is fine (I read that you route certain file types to help with compatibility), but the URL that it’s redirecting to has an expired JWT token appended resulting in an invalid token error instead of the correct .html file. The expiry time is set to the current (now()) epoch, so it is invalid by the time it’s sent back to the browser.
We can only assume that perhaps the clocks have gone forward and the server which generated the JWT hasn’t updated it’s clock?
We started to have an issue with screenshots saved from E2E browser tests, if you open up a file, it shows: {“message”:“not found”} instead of a screenshot. And the URL seems to have private path as well. This is very inconvenient as we rely on screenshots to capture the issue with the test.
UPD: all other artifacts are working fine. So maybe it’s a completely different issue and I need to open a new topic for it. Please advise.
Hi All,
We have implemented some changes on our end in regards to project tokens, as well as being able to access artifacts for open source projects. If anyone is still having issues with new builds, I ask that you submit a support ticket so that we can take a closer look:
Thank you!
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.