Setting expiration labels without an organization and without modifying the Containerfile

64 views
Skip to first unread message

Alex C

unread,
Oct 12, 2023, 10:40:54 AM10/12/23
to quay-sig
Hi,

I'm writing some small builds scripts to build images for personal use (my blog) using a build pack. I'm using a container that can build an image and push it to an image registry (by providing registry credentials).

I would like to set an expiry date for those images, but given there's no Containerfile and the builder I'm using doesn't have labelling features, I can't do it directly.

I am pushing the images to the public quay.io instance. I thought about using the API, but it seems that this requires an organization. I can create an organization, but this seems overkill, and requires setting up an additional email address.

Is there another way to achieve this?

Cheers,

Álex

bdet...@redhat.com

unread,
Oct 12, 2023, 1:26:47 PM10/12/23
to quay-sig
Hi Alex- I'm not aware of another way to set expiration labels, but you can convert your quay.io individual account into an organization directly (no need to create a separate organization). If you go into the User Settings page, the Account Type setting can do a one time (irreversible) conversion into an organization. The only caveat is your quay.io account can't already be part of another organization.

Ivan Bazulic

unread,
Oct 12, 2023, 1:33:51 PM10/12/23
to bdet...@redhat.com, quay-sig
Note that e-mails for orgs are not strictly enforced (lke, strictly checked), only the format of the e-mail address must be correct. So putting foo...@bleh.com should work if there isn't any other org with that e-mail already present. So you don't have to strictly set up a new e-mail address for the org account. The org e-mail is only ever useful for huge orgs with multiple admin accounts. If one tries to get a password reset token for an e-mail address that is connected to an org account, they'll actually get a list of admin accounts back instead of the reset token.

So in your case, creating an org account and then putting any non-used e-mail should be fine. 

--
You received this message because you are subscribed to the Google Groups "quay-sig" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quay-sig+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quay-sig/7ca82c0a-e363-4600-a749-8a2dc12a2a61n%40googlegroups.com.


--

IVAN BAŽULIĆ

PRINCIPAL SUPPORT ENGINEER

Red Hat Canada Ltd.

90 Eglinton Ave E,
Suite 502,
Toronto, ON M4P 2Y3

ibaz...@redhat.com    M: +385959269281     IM: ibazulic

Alex C

unread,
Oct 12, 2023, 2:00:21 PM10/12/23
to quay-sig
Thanks!

My brain does not like creating a fake org with a fake email. I wish robot accounts could use the API somehow; if I follow this path, then my build job requires one set of credentials (the robot account) and then setting the labels requires another set of credentials (the OAuth token). However, if this is the way...

I think I'll explore having my CI job purge tags for deleted branches too. In a way that makes a bit more sense (e.g. remove a build for a branch once the branch is merged or discarded), OTOH it's a bit uglier (manual step- whereas expiry is automatic).

Cheers,

Álex

Ivan Bazulic

unread,
Oct 12, 2023, 2:16:21 PM10/12/23
to Alex C, quay-sig
Hey Alex,

Unfortunately, we don't have the ability to create API tokens on behalf of robot accounts yet. We do have that as a feature request in the backlog but it's some time away from being implemented. So for now the only two choices are: apply the label on build time or create a "fake" org to get API access.

--
You received this message because you are subscribed to the Google Groups "quay-sig" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quay-sig+u...@googlegroups.com.

Alex C

unread,
Oct 12, 2023, 2:17:48 PM10/12/23
to quay-sig
Unfortunately, we don't have the ability to create API tokens on behalf of robot accounts yet. We do have that as a feature request in the backlog but it's some time away from being implemented. So for now the only two choices are: apply the label on build time or create a "fake" org to get API access.

No worries, that's fine! I understand that most people needing these features will be using an organization :)
Reply all
Reply to author
Forward
0 new messages