As a first-time user creating a runner, there's an option to leave the creation flow before completing all steps, including the one to bring your runner online. Users have to confirm they want to leave the page, but they have no way of picking back up where they left off.
Even if a user were to use the CLI to create their runner, they could end up in a scenario where the runner shows that never contacted in the UI and the user then wants to bring it online.
Proposal
Add a Copy run command button for never contacted runners that copies the gitlab-runner run command to their clipboard.
Present a popover on hover with more information.
Present a toast after the copy is successful with Copied text.
@ajwalker We were discussing this previously in the MR for this feature: !112487 (merged). Is there a chance that runner would know the best way to bring itself online? Currently, when you create a new runner, we provide you an optional step to bring it online: gitlab-runner run. The goal is to ensure the runner can pick up jobs once registered.
@gdoyle Sorry for not getting back to you sooner about this.
Yes, I think we could probably determine how runner is installed after they've called gitlab-runner register and provide better instructions on how to "run" their Runner.
Having said that, I'm wondering if we should be deprecating register command entirely (gitlab-runner!4247 (comment 1508441473)), and perhaps not show any instructions in the UI when getting a token. Any instructions placed here are mostly going to be useless all but for the simplest of Runner setups. There's too many needed configuration options that we don't delve into unless you're following some other reference.
A flow I'm familiar with elsewhere, mostly when dealing with cloud platform SDKs, is one where the documentation and getting started guides instruct you on where to get your token from. The page that gives you the token only gives you the token, because there's just so many different ways it can be used to list them all there.
Yes, I think we could probably determine how runner is installed after they've called gitlab-runner register and provide better instructions on how to "run" their Runner.
@ajwalker Do we capture anything about how runner is installed today when users register their runners? Wondering if this would need to be a new feature added on the backend first to capture it.
Having said that, I'm wondering if we should be deprecating register command entirely (gitlab-runner!4247 (comment 1508441473)), and perhaps not show any instructions in the UI when getting a token. Any instructions placed here are mostly going to be useless all but for the simplest of Runner setups. There's too many needed configuration options that we don't delve into unless you're following some other reference.
One of the problems we hear consistently in GitLab SUS surveys is about how difficult it is to start using runners (#39281 (closed)). While a simple setup may not work for everyone, it would get a basic user started with runners. There's certainly room to improve that, maybe we could select some specific use cases we know our users are using runners for and provide them instructions on how to set up runners to work for that. Something similar to GKE quickstarts. The main point is we still need to make it easy as possible to create a runner.
As for deprecating the gitlab-register command, I think we should discuss this with the Runner team. In short, the new creation workflow already is confusing because users are really creating a runner configuration first and could link multiple runners to it. We're shortly going to be exposing runner configurations in the UI so it becomes a little less confusing, but we don't want to overload users with changes.
@ajwalker Do we capture anything about how runner is installed today when users register their runners? Wondering if this would need to be a new feature added on the backend first to capture it.
We don't currently. But also, the next instructions could be printed to the CLI after they run register, rather than being present in the UI I guess?
We're shortly going to be exposing runner configurations in the UI so it becomes a little less confusing
Do we have an issue for this? It depends on the situation, but there's many cases where I wouldn't want the config in the UI. Most config is intended to be Runner-side only, and in some cases you wouldn't want to reveal that to GitLab.
We don't currently. But also, the next instructions could be printed to the CLI after they run register, rather than being present in the UI I guess?
@ajwalker That'd be pretty nice and would actually lead to fewer people having never contacted runners since they'll be prompted to use whatever command is outputted in the CLI while registering. The issue now is that sometimes users don't run gitlab-runner run (for the super simple use case where you just need a single shell runner on your mac to test an MR for example), and then they don't know how to bring them online.
Do we have an issue for this? It depends on the situation, but there's many cases where I wouldn't want the config in the UI. Most config is intended to be Runner-side only, and in some cases you wouldn't want to reveal that to GitLab.
Yes! To clarify, we weren't planning on exposing the whole runner config in the UI, really just making it clear that the list of runners is runner configs, and then you have 1 or many runners linked to it. You can read more in Make it clear what a runner configuration is in... (#420784 - closed). Could be that the title is misleading
Instead of concentrating on providing the user with the most accurate command to bring their never contacted runner online (as we haven't gotten any feedback on gitlab-runner run not working so far), we should focus on the use case where:
First-time user leaves the runner creation form before they complete the whole creation process.
A user who is using the CLI creates a runner, but sees it's never contacted in the UI and wants to bring it online.
Gina Doylechanged the descriptionCompare with previous version