Commit 075f59b8 authored by Steve Azzopardi's avatar Steve Azzopardi

Add guide on how to reset runners token

parent 87f665e8
...@@ -409,7 +409,7 @@ an access key from the Google console first: ...@@ -409,7 +409,7 @@ an access key from the Google console first:
1. Select "Interoperability" and create an access key 1. Select "Interoperability" and create an access key
1. Make note of the "Access Key" and "Secret" and replace them in the 1. Make note of the "Access Key" and "Secret" and replace them in the
configurations below configurations below
1. In the buckets advanced settings ensure the Access Control option "Set object-level 1. In the buckets advanced settings ensure the Access Control option "Set object-level
and bucket-level permissions" is selected and bucket-level permissions" is selected
1. Make sure you already have a bucket created 1. Make sure you already have a bucket created
...@@ -848,15 +848,24 @@ including (but not restricted to): ...@@ -848,15 +848,24 @@ including (but not restricted to):
* [Project mirroring](../workflow/repository_mirroring.md) * [Project mirroring](../workflow/repository_mirroring.md)
* [Web hooks](../user/project/integrations/webhooks.md) * [Web hooks](../user/project/integrations/webhooks.md)
In the case of CI/CD, variables, you might experience some weird behavior, like In cases like CI/CD variables and Runner authentication, you might
stuck jobs or 500 errors. In that case, you can try removing contents of the experience some unexpected behavior such as:
`ci_group_variables` and `ci_project_variables` tables from the database.
- Stuck jobs.
- 500 errors.
In this case, you are required to reset all the tokens for CI/CD variables
and Runner Authentication, which is described in more detail below. After
resetting the tokens, you should be able to visit your project and the jobs
will have started running again.
CAUTION: **Warning:** CAUTION: **Warning:**
Use the following commands at your own risk, and make sure you've taken a Use the following commands at your own risk, and make sure you've taken a
backup beforehand. backup beforehand.
1. Enter the Rails console: #### Reset CI/CD variables
1. Enter the DB console:
For Omnibus GitLab packages: For Omnibus GitLab packages:
...@@ -889,8 +898,39 @@ backup beforehand. ...@@ -889,8 +898,39 @@ backup beforehand.
1. You may need to reconfigure or restart GitLab for the changes to take 1. You may need to reconfigure or restart GitLab for the changes to take
effect. effect.
You should now be able to visit your project, and the jobs will start
running again. #### Reset Runner registration tokens
1. Enter the DB console:
For Omnibus GitLab packages:
```sh
sudo gitlab-rails dbconsole
```
For installations from source:
```sh
sudo -u git -H bundle exec rails dbconsole RAILS_ENV=production
```
1. Clear all the tokens for projects, groups, and the whole instance:
CAUTION: **Caution:**
The last UPDATE operation will stop the runners being able to pick up
new jobs. You must register new runners.
```sql
-- Clear project tokens
UPDATE projects SET runners_token = null, runners_token_encrypted = null;
-- Clear group tokens
UPDATE namespaces SET runners_token = null, runners_token_encrypted = null;
-- Clear instance tokens
UPDATE application_settings SET runners_registration_token_encrypted = null;
-- Clear runner tokens
UPDATE ci_runners SET token = null, token_encrypted = null;
```
A similar strategy can be employed for the remaining features - by removing the A similar strategy can be employed for the remaining features - by removing the
data that cannot be decrypted, GitLab can be brought back into working order, data that cannot be decrypted, GitLab can be brought back into working order,
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment