-
Notifications
You must be signed in to change notification settings - Fork 65
Documentation for service accounts #1184
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
Documentation for service accounts #1184
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
||
Service accounts authenticate using access tokens rather than passwords. For detailed information about creating, managing, and using access tokens, see: | ||
|
||
- [Creating an access token](/cli/how-tos/creating_an_access_token) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ugh, why do these docs live under cli
😆 is that the only access token documentation we have? (sigh)
- Click **Create User** | ||
- Enter a descriptive **Username** (e.g., `ci-automation`, `api-integration`) | ||
- Check the **Service account** checkbox | ||
- Click **Create service account** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a judgement but do our users need that level of detail? Or is our user creation flow that bad?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think our user creation flow is particularly bad, it's pretty straightforward. This has just kinda been the default mode of docs writing 🤷♂️ perhaps it's a bad practice, and just saying "you can create them here" is good enough
Adds some documentation for service accounts, how to create them, manage them, add permissions, etc.
Pull Request approval
You will need to get your PR approved by at least one member of the Sourcegraph team. For reviews of docs formatting, styles, and component usage, please tag the docs team via the #docs Slack channel.