I use private buckets for build artifacts. I set up a proxy to serve the content but it runs on an internal DNS. I am trying to add a build annotation that displays three images that are generated when a particular test fails (reference, generated and difference). Unfortunately, it seems the annotation puts a proxy (camo.buildkiteusercontent.com) in front of the actual image source and moves the source to a data-canonical-src attribute on the image tag. This obviously doesn’t work because the src is not accessible outside of our VPN. It would be very nice if the annotation could be configured to use the actual artifact path in this situation.
This is a pretty interesting situation @pagameba and not something I had considered before.
Are you using the special artifact syntax (artifact://) to reference an image, or embedding the path directly?
As you noticed, we force all images to proxy through a tool called camo:
Using camo.buildkiteusercontent.com gives us a few benefits:
- Allows us to enforce all images to be served over HTTPS fixing mixed content warnings (this is the biggest one)
- We can restrict the size of images (stopping you accidentally rendering 1gb gif)
- Only allow certain image types to be proxied
For those reasons, I don’t think we’ll be allowing any exceptions to that rule any time soon (unless we can think of a better way to get those guarantees we’re after without using camo, or we can think of a secure way of allowing private artifacts to be embedded).
In saying that though, there’s no reason we can’t work out a different way to achieve what you’re after! I’m keen to work with you and figure out a solution!
As a first suggestion, could you potentially poke a whole in your VPN allowing the camo IP address to access images? (assuming you’re using S3?)
I tried using both artifact:// and a straight-up image src, both result in the camo URL. The artifacts are indeed stored in S3. As recommended in your documentation, I am running aws-s3-proxy but this is running internal to our VPN on a private DNS. I suppose that could be exposed via public facing ALB, or I can modify the bucket policy to grant access from a specific IP or account/role, but seems to defeat the purpose of making all this private in the first place? In my particular use case, the images that I want to use for annotations could be stored publicly. I could use aws s3 cp to move them to a specific bucket location that is public read, i.e. not use artifacts at all. I’m going to try this :)