Launchpad itself

Get links to OCI build files from API

Asked by Tomáš Virtus

Hello,

We (CPC & ROCKs) would like to move OCI publishing from Launchpad to Jenkins. We'd still like Launchpad to build OCI images. I'm browsing through API of https://api.launchpad.net/devel.html#oci_recipe_build and I see no way to get list of links to built files. For instance, if I wanted to download built files from https://launchpad.net/~ubuntu-docker-images/ubuntu-docker-images/+oci/bind9/+recipe/bind9-22.04/+build/4120 via API, is there any way to do that with current API?

TIA!

Question information

Language:
English Edit question
Status:
Solved
For:
Launchpad itself Edit question
Assignee:
No assignee Edit question
Solved by:
Colin Watson
Solved:
Last query:
Last reply:
Revision history for this message
Colin Watson (cjwatson) said : 		#1

How does this plan comport with the plan of record to get OCI publishing working via Harbor? I mean, I'm painfully aware that we're really behind on getting that set up, but I'm not sure that moving to Jenkins is necessarily a step forward ...

Anyway, it wouldn't be too hard to add a method to return URLs for all the files produced by a given build (`SnapBuild` has an exported `getFileUrls` method, and this could follow that pattern). Please use "Create bug report" to convert this question into a bug report.

Revision history for this message
Cristovao Cordeiro (cjdc) said : 		#2

right now, the only use case for having these LP API methods would be for simplifying the publishing and tagging mechanisms.

Harbor would indeed (potentially), simplify all this.

There are two things we want to work on:
 1. consistent and single source of tagging: right now, LP builds and publishes a single container image tag, to multiple registries. We later fetch that tag, re-tag and re-publish to all registries. It is an unnecessary back and forward. Harbor could help a lot here I presume
 2. faster support for new registries: with time we'll potentially proliferate our images to N registries. Right now we have ACR ongoing and OCR in the pipeline. The problem is that for every new registry we might need to put forward a request for allowing access to said registry from LP (eg. https://rt.admin.canonical.com/Ticket/Display.html?id=136024). These requests can, understandingly, take time. We also need to make the same request for Jenkins anyway since we're also publishing from there.

In short, I'd say:
 - this is not a critical request, but rather an effort to improve the current workflows
 - if LP does not provide said API methods, then I'd let the LP team decide on whether this is easy/worth/fast to implement. If the answer is "no", then we just wait for Harbor and try to escalate the LP proxy requests

Revision history for this message
Best Colin Watson (cjwatson) said : 		#3

Regarding your second point, it takes exactly as long to make this change for Jenkins as for Launchpad, and they can both be done at the same time, so this won't make a practical difference. Although we need IS to actually make the change, it's nearly always better to make this sort of request for Launchpad connectivity via the Launchpad team; IS will usually check access requests with the service owners anyway, and we'd have sorted this out for you weeks ago if we'd known about it. I've updated that ticket with a merge proposal.

I think it'll be fine to add a method to get download URLs for files (though note that they expire in a week or so, and if you take this approach then you'll have to deal with reassembling the layers yourself). We don't track feature requests using questions, though, which is why I asked for this question to be converted into a bug report using the "Create bug report" option in the web UI.

Revision history for this message
Cristovao Cordeiro (cjdc) said : 		#4

> it's nearly always better to make this sort of request for Launchpad connectivity via the Launchpad team;

thanks for the tip. And thanks for pushing the MP forward for the LP proxy.

As for this LP API method, we've used the question also to get more information, which you've provided we appreciate that. Given the provided information, we'll talk about it internally and take the necessary action, ultimately created the bug report as suggested ;)

Revision history for this message
Tomáš Virtus (virtustom) said : 		#5

Thanks Colin Watson, that solved my question.