actions/importer-labs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Readme edits

Browse Source
This commit is contained in:
Jennifer Kerns
2022-09-13 08:55:51 -04:00
committed by GitHub
parent 15d5df048d
commit a3f2fe338f
22 changed files with 287 additions and 287 deletions
Download Patch File Download Diff File Expand all files Collapse all files
gitlab/1-configure.md
+20 -20
View File
@@ -6,7 +6,7 @@ You will need to complete all of the setup instructions [here](./readme.md#confi
## Configuring credentials
1. Run the setup script in the codespace's terminal to ensure the GitLab server is ready:
1. Run the setup script in the codespace terminal to ensure the GitLab server is ready:
```bash
./gitlab/bootstrap/setup.sh
```
@@ -16,40 +16,40 @@ You will need to complete all of the setup instructions [here](./readme.md#confi
- In the `PORTS` tab find the row for port 80.
- Hover over the address under the `Local Address` column and click the globe to "open in browser".
3. Create a GitLab personal access token:
3. Create a GitLab personal access token (PAT):
- Authenticate with the GitLab server using the following credentials:
- Username: `root`
- Password: `valet-labs!`
- Follow the GitLab [instructions](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token) to generate a personal access token.
- Follow the GitLab [instructions](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token) to generate a PAT.
- Ensure the token has the `read_api` scope.
- Copy the generated token and save in a safe location.
- Copy the generated token and save it in a safe location.
4. Create a GitHub Personal Access Token (PAT):
4. Create a GitHub personal access token (PAT):
- Open github.com in a new browser tab.
- Click your profile photo in the top right of the UI and click `Settings`.
- Click on `Developer Settings` in the left hand panel.
- Click `Personal Access Tokens` and then `Legacy tokens` (if present).
- Click `Generate new token` and then `Legacy tokens`. You may be required to authenticate with GitHub during this step.
- Select the following scopes: `read:packages` and `workflow`.
- In the top right corner of the UI, click your profile photo and click `Settings`.
- In the left panel, click `Developer Settings`.
- Click `Personal access tokens` and then `Legacy tokens` (if present).
- Click `Generate new token` and then `Generate new legacy token`. You may be required to authenticate with GitHub during this step.
- Select the following scopes: `workflow` and `read:packages`.
- Click `Generate token`.
- Copy the generated PAT and save in a safe location.
- Copy the generated PAT and save it in a safe location.
4. Run the `configure` CLI command:
5. Run the `configure` CLI command:
- Select the `TERMINAL` tab from within the codespace terminal window.
- Run the following command: `gh valet configure`.
- Using the down arrow key to highlight `GitLab CI`, press the spacebar to select, and then hit enter to continue.
- At the prompt enter your GitHub Username and press enter.
- At the GitHub Container Registry prompt enter the GitHub PAT generated in step 4 and press enter.
- At the GitHub PAT prompt enter the GitHub PAT generated in step 4 and press enter.
- At the GitHub url prompt enter the GitHub instance url or hit enter to accept the default value (`https://github.com`).
- At the GitLab CI token prompt enter the GitLab CI access token from step 3 and press enter.
- At the GitLab CI url prompt enter `http://localhost` and press enter.
- Use the down arrow key to highlight `GitLab CI`, press the spacebar to select, and then press enter to continue.
- At the prompt, enter your GitHub username and press enter.
- At the GitHub Container Registry prompt, enter the GitHub PAT generated in step 4 and press enter.
- At the GitHub PAT prompt, enter the GitHub PAT generated in step 4 and press enter.
- At the GitHub URL prompt, enter the GitHub instance URL or press enter to accept the default value (`https://github.com`).
- At the GitLab CI token prompt, enter the GitLab CI access token from step 3 and press enter.
- At the GitLab CI URL prompt, enter `http://localhost` and press enter.
![img](https://user-images.githubusercontent.com/18723510/183990474-d0b2559c-d2bf-40d9-ac43-19af53e45329.png)
## Verify your environment
To verify our environment is configured correctly, we are going to run the `update` CLI command. The `update` CLI command will download the latest version of Valet to your codespace.
To verify your environment is configured correctly, run the `update` CLI command. The `update` CLI command will download the latest version of Valet to your codespace.
1. In the codespace terminal run the following command:
gitlab/2-audit.md
+10 -10
View File
@@ -6,18 +6,18 @@ The `audit` command operates by fetching all of the pipelines defined in a GitLa
## Prerequisites
1. Followed the steps [here](./readme.md#configure-your-codespace) to set up your Codespace environment and start a GitLab server.
1. Followed the steps [here](./readme.md#configure-your-codespace) to set up your GitHub Codespaces environment and start a GitLab server.
2. Completed the [configure lab](./1-configure.md#configuring-credentials).
## Perform an audit
We will be performing an audit against your preconfigured GitLab server. We will need to answer the following questions before running this command:
You will be performing an audit against your preconfigured GitLab server. Answer the following questions before running this command:
1. What namespace (e.g. group) do we want to audit?
- __valet__. In this example we will be auditing the `valet` group. In the future, you could add additional groups and subgroups to the audit command.
1. What namespace (e.g. group) do you want to audit?
- __valet__. In this example you will be auditing the `valet` group. In the future, you could add additional groups and subgroups to the audit command.
2. Where do we want to store the result?
- __./tmp/audit__. This can be any path within the working directory that Valet commands are executed from.
2. Where do you want to store the result?
- __./tmp/audit__. This can be any path within the working directory from which Valet commands are executed.
### Steps
@@ -34,7 +34,7 @@ We will be performing an audit against your preconfigured GitLab server. We will
1. Find the `audit_summary.md` file in the file explorer.
2. Right-click the `audit_summary.md` file and select `Open Preview`.
3. This file contains details that summarizes what percentage of your pipelines were converted automatically.
3. This file contains details that summarize what percentage of your pipelines were converted automatically.
### Review audit summary
@@ -68,7 +68,7 @@ Here are some key terms in the “Pipelines” section in the above example:
- __Successful__ pipelines had 100% of the pipeline constructs and individual items converted automatically to their GitHub Actions equivalent.
- __Partially successful__ pipelines had all of the pipeline constructs converted, however, there were some individual items (e.g. build tasks or build triggers) that were not converted automatically to their GitHub Actions equivalent.
- __Unsupported__ pipelines are definition types that are not supported by Valet. Auto DevOps pipelines are not supported.
- __Failed pipelines__ encountered a fatal error when being converted. This can occur for one of three reasons:
- __Failed__ pipelines encountered a fatal error when being converted. This can occur for one of three reasons:
- The pipeline was misconfigured and not valid in GitLab.
- Valet encountered an internal error when converting it.
- There was an unsuccessful network response, often due to invalid credentials, that caused the pipeline to be inaccessible.
@@ -176,8 +176,8 @@ Each pipeline will have a variety of files written that include:
- The original pipeline as it was defined in GitLab.
- Any network responses used to convert a pipeline.
- The converted workflow.
- Stack traces that can used to troubleshoot a failed pipeline conversion
- Stack traces that can be used to troubleshoot a failed pipeline conversion
### Next lab
[Perform a dry-run of a GitLab pipeline](3-dry-run.md)
[Perform a dry-run migration of a GitLab pipeline](3-dry-run.md)
gitlab/3-dry-run.md
+11 -11
View File
@@ -1,4 +1,4 @@
# Perform a dry-run of a GitLab pipeline
# Perform a dry-run migration of a GitLab pipeline
In this lab you will use the `dry-run` command to convert a GitLab pipeline to its equivalent GitHub Actions workflow.
@@ -10,20 +10,20 @@ In this lab you will use the `dry-run` command to convert a GitLab pipeline to i
## Perform a dry run
We will be performing a dry-run against a pipeline in your preconfigured GitLab server. We will need to answer the following questions before running this command:
You will be performing a dry run against a pipeline in your preconfigured GitLab server. Answer the following questions before running this command:
1. What is the project we want to convert?
1. What project do you want to convert?
- __basic-pipeline-example__
2. What is the namespace for that project?
- __Valet__
3. Where do we want to store the result?
- __./tmp/dry-run-lab__. This can be any path within the working directory that Valet commands are executed from.
3. Where do you want to store the result?
- __./tmp/dry-run-lab__. This can be any path within the working directory from which Valet commands are executed.
### Steps
1. Navigate to the codespace terminal
1. Navigate to your codespace terminal
2. Run the following command from the root directory:
```bash
@@ -35,7 +35,7 @@ We will be performing a dry-run against a pipeline in your preconfigured GitLab
![img](https://user-images.githubusercontent.com/18723510/184173635-aec28d1c-8c61-4dcf-a743-f86cbdc836c5.png)
4. View the converted workflow:
- Find `./tmp/dry-run/valet` in the file explorer pane in codespaces.
- Find `./tmp/dry-run/valet` in the file explorer pane in your codespace.
- Click `basic-pipeline-example.yml` to open.
## Inspect the output files
@@ -198,11 +198,11 @@ jobs:
```
</details>
Despite these 2 pipelines using different syntax they will function equivalently.
Despite these two pipelines using different syntax they will function equivalently.
## Perform a dry-run of a pipeline using `include`'d files
## Perform a dry-run migration of a pipeline using `include`'d files
The previous example demonstrated a basic pipeline that mapped exactly to concepts in GitHub Actions. In this section, we will perform a dry-run of the `included-files-example` pipeline that uses the `include` statement in GitLab:
The previous example demonstrated a basic pipeline that mapped exactly to concepts in GitHub Actions. In this section, you will perform a dry run of the `included-files-example` pipeline that uses the `include` statement in GitLab:
```yaml
include:
@@ -247,7 +247,7 @@ jobs:
It's important to note that Valet converted this into a single workflow without templates. This is because of fundamental differences in how GitLab templates and GitHub Actions templates (i.e. Reusable Workflows and Composite Actions) function in regards to job ordering. Unfortunately, elements of reusability will be sacrificed in order for the converted pipelines to function the same. It is likely that the output of Valet could be refactored to use [reusable workflow](https://docs.github.com/en/actions/using-workflows/reusing-workflows) at a later date.
As an added challenge, try constructing and running the `dry-run` command yourself. Hint, you should just have to change the project name.
As an added challenge, try constructing and running the `dry-run` command yourself. Hint, you should only have to change the project name.
## Next lab
gitlab/4-custom-transformers.md
+13 -13
View File
@@ -1,6 +1,6 @@
# Using custom transformers to customize Valet's behavior
In this lab we will build upon the `dry-run` command to override Valet's default behavior and customize the converted workflow using "custom transformers". Custom transformers can be used to:
In this lab you will build upon the `dry-run` command to override Valet's default behavior and customize the converted workflow using "custom transformers". Custom transformers can be used to:
1. Convert items that are not automatically converted.
2. Convert items that were automatically converted using different actions.
@@ -9,13 +9,13 @@ In this lab we will build upon the `dry-run` command to override Valet's default
## Prerequisites
1. Followed the steps [here](./readme.md#configure-your-codespace) to set up your Codespace environment and start you GitLab server.
1. Followed the steps [here](./readme.md#configure-your-codespace) to set up your GitHub Codespaces environment and start you GitLab server.
2. Completed the [configure lab](./1-configure-lab.md#configuring-credentials).
3. Completed the [dry-run lab](./3-dry-run.md).
## Perform a dry-run
We will be performing a `dry-run` command to inspect the workflow that is converted by default. Run the following command within the codespace terminal:
You will be performing a `dry-run` command to inspect the workflow that is converted by default. Run the following command within the codespace terminal:
```bash
gh valet dry-run gitlab --output-dir tmp --namespace valet --project terraform-example
@@ -57,13 +57,13 @@ _Note_: You can refer to the previous [lab](./3-dry-run.md) to learn about the f
## Custom transformers for an unknown step
The converted workflow above contains an `artifacts.terraform` step was not automatically converted. We will need to answer the following questions before writing a custom transformer:
The converted workflow above contains an `artifacts.terraform` step that was not automatically converted. Answer the following questions before writing a custom transformer:
1. What is the "identifier" of the step to customize?
- __artifacts.terraform__
2. What is the desired Actions syntax to use instead?
- After some research, we have determined that the following bash script will provide similar functionality:
- After some research, you have determined that the following bash script will provide similar functionality:
```yaml
- uses: actions/upload-artifact@v3
@@ -71,13 +71,13 @@ The converted workflow above contains an `artifacts.terraform` step was not auto
path: VALUE_FROM_GITLAB
```
Now we can begin to write the custom transformer. Customer transformers use a DSL built on top of Ruby and should be defined in a file with the `.rb` file extension. You can create this file by running the following command in your codespace terminal:
Now you can begin to write the custom transformer. Custom transformers use a DSL built on top of Ruby and should be defined in a file with the `.rb` file extension. You can create this file by running the following command in your codespace terminal:
```bash
code transformers.rb
```
Next, we will define a `transform` method for the `artifacts.terraform` identifier by adding the following code to `transformers.rb`:
Next, you will define a `transform` method for the `artifacts.terraform` identifier by adding the following code to `transformers.rb`:
```ruby
transform "artifacts.terraform" do |item|
@@ -92,7 +92,7 @@ end
This method can use any valid ruby syntax and should return a `Hash` that represents the YAML that should be generated for a given step. Valet will use this method to convert a step with the provided identifier and will use the `item` parameter for the original values configured in GitLab.
Now, we can perform another `dry-run` command and use the `--custom-transformers` CLI option to provide this custom transformer. Run the following command within your codespace terminal:
Now you can perform another `dry-run` command and use the `--custom-transformers` CLI option to provide this custom transformer. Run the following command within your codespace terminal:
```bash
gh valet dry-run gitlab --output-dir tmp --namespace valet --project terraform-example --custom-transformers transformers.rb
@@ -107,7 +107,7 @@ The converted workflow that is generated by the above command will now use the c
+ path: "$PLAN_JSON"
```
_Note_: If you were unsure what the data structure of `item` was then you could use the following code in the custom transformer to print `item` to the console:
_Note_: If you were unsure what the data structure of `item` was, you could use the following code in the custom transformer to print `item` to the console:
```ruby
transform "artifacts.terraform" do |item|
@@ -117,7 +117,7 @@ end
## Custom transformers for environment variables
We can also use custom transformers to edit the values of environment variables in converted workflows. In our example, we will be updating the `PLAN_JSON` environment variable to be `custom_plan.json` instead of `plan.json`.
You can also use custom transformers to edit the values of environment variables in converted workflows. In this example, you will update the `PLAN_JSON` environment variable to be `custom_plan.json` instead of `plan.json`.
To do this, add the following code to the `transformers.rb` file.
@@ -127,7 +127,7 @@ env "PLAN_JSON", "custom_plan.json"
In this example, the first parameter to the `env` method is the environment variable name and the second is the updated value.
Now, we can perform another `dry-run` command with the `--custom-transformers` CLI option. When you open the converted workflow the `PLAN_JSON` environment variable will be set to `custom_plan.json`:
Now you can perform another `dry-run` command with the `--custom-transformers` CLI option. When you open the converted workflow the `PLAN_JSON` environment variable will be set to `custom_plan.json`:
```diff
env:
@@ -136,7 +136,7 @@ Now, we can perform another `dry-run` command with the `--custom-transformers` C
+ PLAN_JSON: custom_plan.json
```
At this point of the lab the file contents of `transformers.rb` should match this:
At this point, the file contents of `transformers.rb` should match this:
<details>
<summary><em>Custom transformers 👇</em></summary>
@@ -156,7 +156,7 @@ At this point of the lab the file contents of `transformers.rb` should match thi
</details>
Thats it! Congratulations you have overridden Valet's default behavior by customizing the conversion of:
That's it! Congratulations, you have overridden Valet's default behavior by customizing the conversion of:
- Unknown steps
- Environment variables
gitlab/5-migrate.md
+7 -7
View File
@@ -4,20 +4,20 @@ In this lab, you will use the `migrate` command to convert a GitLab pipeline and
## Prerequisites
1. Followed the steps [here](./readme.md#configure-your-codespace) to set up your Codespace environment and start a GitLab server.
1. Followed the steps [here](./readme.md#configure-your-codespace) to set up your GitHub Codespaces environment and start a GitLab server.
2. Completed the [configure lab](./1-configure-lab.md#configuring-credentials).
3. Completed the [dry-run lab](./3-dry-run.md).
4. Completed the [custom transformers lab](./4-custom-transformers.md).
## Performing a migration
We need to answer the following questions before running a `migrate` command:
Answer the following questions before running a `migrate` command:
1. What is the project we want to migrate?
1. What project do you want to migrate?
- __rails-example__
2. What is the namespace for that project?
- __Valet__
3. Where do we want to store the logs?
3. Where do you want to store the logs?
- __./tmp/migrate__
4. What is the URL for the GitHub repository to add the workflow to?
- __this repository__. The URL should should follow the pattern <https://github.com/:owner/:repo> with `:owner` and `:repo` replaced with your values.
@@ -38,11 +38,11 @@ We need to answer the following questions before running a `migrate` command:
### Inspect the pull request
The first thing we should notice about the PR is that there is a list of manual steps for us to complete.
The first thing to notice about the pull request is that there is a list of manual steps to complete.
Next, you can inspect the "Files changed" in this PR and see the converted workflow that is being added. Any additional changes or code reviews that were needed should be done in this PR.
Next, you can inspect the "Files changed" in this pull request and see the converted workflow that is being added. Any additional changes or code reviews that were needed should be done in this pull request.
Finally, you can merge the PR once your review has completed. We can then view the workflow running by selecting the "Actions" menu in the top navigation bar in GitHub.
Finally, you can merge the pull request once your review has completed. You can then view the workflow running by selecting the "Actions" menu in the top navigation bar in GitHub.
![img](https://user-images.githubusercontent.com/18723510/184960870-590b1a28-422f-4350-9ec0-0423bf7ad445.png)
gitlab/6-forecast.md
+10 -10
View File
@@ -4,23 +4,23 @@ In this lab you will use the `forecast` command to forecast potential GitHub Act
## Prerequisites
1. Followed the steps [here](./readme.md#configure-your-codespace) to set up your Codespace environment and start a GitLab server.
1. Followed the steps [here](./readme.md#configure-your-codespace) to set up your GitHub Codespaces environment and start a GitLab server.
2. Completed the [configure lab](./1-configure-lab.md#configuring-credentials).
## Perform a forecast
We will need to answer the following questions before running the `forecast` command:
Answer the following questions before running the `forecast` command:
1. What namespace do we want to run the forecast for?
1. What namespace do you want to run the forecast for?
- **valet**
2. What is the date we want to start forecasting from?
2. What is the date you want to start forecasting from?
- **2022-08-02**. This date is needed as it is prior to when the data was seeded in GitLab for these labs. This value defaults to the date one week ago, however, you should use a start date that will show a representative view of typical usage.
3. Where do we want to store the results?
3. Where do you want to store the results?
- **./tmp/forecast_reports**
### Steps
1. Navigate to the codespace terminal
1. Navigate to your codespace terminal
2. Run the following command from the root directory:
```bash
@@ -74,8 +74,8 @@ Here are some key terms of items defined in the forecast report:
- The `job count` is the total number of completed jobs.
- The `pipeline count` is the number of unique pipelines used.
- `Execution time` describes the amount of time a runner spent on a job. This metric can be used to help plan for the cost of GitHub hosted runners.
- This metric is correlated to how much you should expect to spend in GitHub Actions. This will vary depending on the hardware used for these minutes and the [Actions pricing calculator](https://github.com/pricing/calculator) should be used to estimate a dollar amount.
- `Execution time` describes the amount of time a runner spent on a job. This metric can be used to help plan for the cost of GitHub-hosted runners.
- This metric is correlated to how much you should expect to spend in GitHub Actions. This will vary depending on the hardware used for these minutes. You can use the [Actions pricing calculator](https://github.com/pricing/calculator) to estimate a dollar amount.
- `Queue time` metrics describe the amount of time a job spent waiting for a runner to be available to execute it.
- `Concurrent jobs` metrics describe the amount of jobs running at any given time. This metric can be used to define the number of runners a customer should configure.
@@ -83,11 +83,11 @@ Additionally, these metrics are defined for each queue of runners defined in Git
## Forecasting multiple providers
We can examine the available options for the `forecast` command by running `gh valet forecast --help`. When you do this you will see the `--source-file-path` option:
You can examine the available options for the `forecast` command by running `gh valet forecast --help`. When you do this you will see the `--source-file-path` option:
![img](https://user-images.githubusercontent.com/19557880/186263140-f02c6cab-7979-417c-bdfe-b9590e9c5597.png)
The `--source-file-path` CLI option can be used to combine data from multiple reports into a single report. This becomes useful if you use multiple CI/CD providers and wanted to get a holistic view of the runner usage. This works by using the `.json` files generated by `forecast` commands as space-delimited values for the `--source-file-path` CLI option. Optionally, this value could be a glob pattern to dynamically specify the list of files (e.g. `**/*.json`).
You can use the `--source-file-path` CLI option to combine data from multiple reports into a single report. This becomes useful if you use multiple CI/CD providers and want to get a holistic view of the runner usage. This works by using the `.json` files generated by `forecast` commands as space-delimited values for the `--source-file-path` CLI option. Optionally, this value could be a glob pattern to dynamically specify the list of files (e.g. `**/*.json`).
Run the following command from within the codespace terminal:
gitlab/readme.md
+14 -14
View File
@@ -1,25 +1,25 @@
# GitLab to Actions migrations powered by Valet
The instructions below will guide you through configuring a GitHub Codespace environment that will be used in subsequent labs that demonstrate how to use Valet to migrate GitLab pipelines to GitHub Actions.
These instructions will guide you through configuring the GitHub Codespaces environment that will be used in these labs that demonstrate how to use Valet to migrate GitLab pipelines to GitHub Actions.
These steps **must** be completed prior to starting other labs.
## Create your own repository for these labs
1. Ensure that you have created a repository using the [valet-customers/labs](https://github.com/valet-customers/labs) as a template.
- Ensure that you have created a repository using [valet-customers/labs](https://github.com/valet-customers/labs) as a template.
## Configure your Codespace
## Configure your codespace
1. Start the codespace
1. Start a new codespace
- Click the `Code` button on your repository's landing page.
- Click the `Codespaces` tab.
- Click `Create codespaces on main` to create the codespace.
- After the Codespace has initialized there will be a terminal present.
- After the codespace has initialized there will be a terminal present.
2. Verify the Valet CLI is installed and working. More information on the Valet extension for the official GitHub CLI can be found [here](https://github.com/github/gh-valet).
- Run the following command in the codespace's terminal:
- Run the following command in the codespace terminal:
```bash
gh valet version
@@ -33,20 +33,20 @@ These steps **must** be completed prior to starting other labs.
valet-cli unknown
```
- If `gh valet version` did not produce similar output then please follow the troubleshooting [guide](#troubleshoot-the-valet-cli).
- If `gh valet version` did not produce similar output, please refer to the troubleshooting [guide](#troubleshoot-the-valet-cli).
## Bootstrap a GitLab server
1. Execute the GitLab setup script that will start a container with GitLab running inside of it. The script should be executed when starting a new Codespace or restarting an existing one.
1. Execute the GitLab setup script that will start a container with GitLab running inside of it. The script should be executed when starting a new codespace or restarting an existing one.
- Run the following command from the codespace's terminal:
- Run the following command from the codespace terminal:
```bash
./gitlab/bootstrap/setup.sh
```
- After some time, a pop-up box should appear with a link to the URL for your GitLab server.
- You can also access the URL by going to the `Ports` tab in your terminal. Right click on the URL listed under the `Local Address` and click the `Open in Browser` tab.
- You can also access the URL by going to the `Ports` tab in your terminal. Right-click the URL listed under the `Local Address` and click the `Open in Browser` tab.
2. Open the GitLab server in your browser and use the following credentials to authenticate:
@@ -61,7 +61,7 @@ Perform the following labs to learn more about Actions migrations with Valet:
1. [Configure credentials for Valet](1-configure.md)
2. [Perform an audit on GitLab pipelines](2-audit.md)
3. [Perform a dry-run of a GitLab pipeline](3-dry-run.md)
3. [Perform a dry-run migration of a GitLab pipeline](3-dry-run.md)
4. [Use custom transformers to customize Valet's behavior](4-custom-transformers.md)
5. [Perform a production migration of a GitLab pipeline](5-migrate.md)
6. [Forecast potential build runner usage](6-forecast.md)
@@ -71,7 +71,7 @@ Perform the following labs to learn more about Actions migrations with Valet:
The CLI extension for Valet can be manually installed by following these steps:
- Verify you are in the codespace terminal
- Run this command from within the codespace's terminal:
- Run this command from within the codespace terminal:
```bash
gh extension install github/gh-valet
@@ -83,10 +83,10 @@ The CLI extension for Valet can be manually installed by following these steps:
✓ Installed extension github/gh-valet
```
- If you get an error similar to the image below, then click the link in the terminal output to authorize the token.
- If you get an error similar to the image below, click the link in the terminal output to authorize the token.
- Restart the codespace after clicking the link.
![img](https://user-images.githubusercontent.com/26442605/169588015-9414404f-82b6-4d0f-89d4-5f0e6941b029.png)
- Verify Valet CLI extension is installed and working by running the following command from the codespace's terminal:
- Verify Valet CLI extension is installed and working by running the following command from the codespace terminal:
```bash
gh valet version