-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Container Retention Policy #3474
Conversation
while only keeping at least 12 to try and archive one image for each month over the year to date
while only keeping at least 1 to try and archive only one image per month
to alias over github repository name
@SteveMacenski , could you please create new PAT for the and add to the If you see something akin to this prompt, you can decide if/how you'd like to approve each fine-grained personal access token that can access the organization. |
Alternately, I'm also thinking of forgoing our current timestamp tagging approach, and perhaps tagging the CI images by the current release version instead: https://github.com/ros-planning/navigation2/releases As that seems to have a much lower cadence, and would be semantically more relevant if needing to pull an old image from the archive. Thus each tag would retain the most recently build CI image with a build environment targeting that version. E.g:
In retrospect, timestamping the image tags now seems a bit overkill, given we haven't had to roll back and pin our CI image for quite a while. |
@tfoote is there a way to generate a PAT for the organization rather than being hooked into my personal account? I'm a little weary about creating a PAT that can access my account stored in github's servers in case of hacking (which seems to be the theme of the day). Restricting it to Nav2 at the org level would be the safest bet. The biggest thing of using the release tags is that the |
@SteveMacenski , as an admin, are you able to view the orgs settings page? https://github.com/organizations/ros-planning/settings/personal-access-tokens-onboarding This should be where one can generate PATs for the organization, rather than specific to a user account. However, this page is marked as beta for orgs I own.
I was just thinking of having the CI read the version number from the package file, and tagging the image with the same version number string. So until you bump up the version in the code, the action would just push the generated image to the same tag in the image registry. So even if commits frequently cause the CI image to rebuild, we would still have clear demarcations of the main image's history via the version bumps. |
Yeah, I can see that page but I don't see any way via it to add a PAT. I'm wondering if its because its not possible or if I don't have the permissions to see that capability. All I see on that page are toggles to allow PATs. Sure, but then the If the rebuilding is in GitHub Actions (free to us), why not just update it in some regular cadence? |
Oh, so when first enrolling and enabling org level PATs, this is what I see fair one of my other orgs: With those being still being the most conservative choices over the three enrollment options, any admin can navigate to here to create a fine-grained PAT: Unfortunately, with fine-grained personal access tokens still under beta, that notably allow for setting the organization as the resource owner, it looks like not all the necessary endpoints are mapped to listed permissions under the drop-down menus when creating a fine-grained token. However, I can see the necessary permissions where viewing creating a classic token, specifically the read and delete permissions for packages: With packages being hosted by the organization, rather than under a specific repo, my guess is that they haven't yet extended the UI to express those kind of associative permissions. @nuclearsandwich , forgive me for pinging you yet again, but as our GitHub guru, I figured this would be a familiar topic to you. |
I think it might be useful if you had admin permissions to poke around. You're a known responsible party. @nuclearsandwich @tfoote any objections? We could also potentially make a |
We've used a bot before for managing docker related tasks over on osrf/docker_imsges, although I'm not sure we'd want to reuse it across multiple orgs. Principle of least privilege and what not. Why did GitHub make it so hard to use minimally scoped tokens? https://github.com/osrf-docker-builder BTW, That bot still need some attention, as I suspect it's PATs have expired, thus it falling dormant. We'd love for it to come back: |
Yeah, historically we've used a dedicated bot account which is given minimum access requirements to do the necessary operations. |
@tfoote can we give Ruffin appropriate permissions in the org? He's pretty regular in doing odd stuff like this which require elevated privileges. |
Replaced by #3491 after continuing this thought: #3474 (comment) . |
To try and archive only one image per month over the past year to date.
As we seem to be hoarding a large number of old images, and I'd rather not have to manually deleting them from the web UI.