(So far I used this cloud.init script to spin up and upgrade GitLab-Runner instants: https://gitlab.com/21analytics/gitlab-runner-cloud-init/-/bl...)
> Grants complete read/write access to the API, including all groups and projects, the container registry, the dependency proxy, and the package registry.
Even more so just to stay informed about updates.
We wanted to make the onboarding as simple as possible so that we can:
0. Log you in through your existing GitLab.com or GitLab self-hosted account 1. List all your groups and projects to decide where to install the runner 2. Disable GitLab.com's own instance runners (otherwise our Runners are not picked up) 3. Install the Runner 4. Optionally: When installing an agent runner, we are able to reply to read and reply to all your issues where you tag us via `@Rocket` -- this runs completely on your machine that we host for you! It doesn't run on our infrastructure and we only access your runner machine for auto-cleaning its caches.
That's really all the RocketRunner does with you granting us permissions when logging in.
We are looking into ways how to possible scope access better! Thanks for your feedback!
The worst part about the github runner setup is that there is no built in support for using your own cache if you are using github.com and want to run your own runners. In order to use your own cache store for your runner jobs, you have to patch the runner image because the cache location is hard coded. Gitlab lets you choose your cache location as a standard feature.
P.S.: With AdBlockers enabled I cannot navigate on your site at all on Safari mobile. Seems like your navigation uses to much JS to provide a link.