...
Well, the worse news is that we cannot run a CI job to prune the artifacts automatically, because one would need a personal access token for that. Why personal access token? Because Project/Group access tokens are apparently unavailable on GitLab SaaS if you're not a paying customer (which is weird, because most other features from Ultimate are enabled) [2] and in fact I don't see the described setting under our group/project just like this guy [3].
The problem with Personal access tokens is that there are security implications tied to them: - linked to a specific user - other users with high enough privileges could see the token - wrong settings can lead to leaking of that token which could expose all repositories of that user
One possible solution would be to create a member service account with no repositories. The password would only be available to the maintainers. AFAIK you don't need full API access to purge pipelines, IOW read_api permissions should suffice which means it would not make this such an awfully ugly solution.
Forget about ^this one, I just tried and full API access permission is required on the token which renders ^this a no-go from security POV. Regards, Erik
The proper solution would be to use CI/CD job tokens because these are ephemeral by design, however they have no permission granularity settings and so cannot be used with all of the API endpoints (purging artifacts being one of them) :(.
The least favourable solution IMO (but 100% functional) would be for one of the to set up a cron job on a private machine using their private access token which nobody could see and purge them from "the outside".
[1] https://docs.gitlab.com/ee/ci/variables/where_variables_can_be_used.html#git... [2] https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html [3] https://forum.gitlab.com/t/project-access-token-isnt-visible/51701
In any case I'll put this patch on hold until we have a clear idea what the best course of action is - we still have a month™.
Erik