Merge branch 'feature/circleci-labs' of https://github.com/valet-customers/labs into luke-edits
This commit is contained in:
Luke Engle
@@ -2,20 +2,31 @@
|
||||
"name": "Codespace to perform Valet Labs",
|
||||
"image": "mcr.microsoft.com/vscode/devcontainers/universal:linux",
|
||||
"remoteUser": "codespace",
|
||||
"overrideCommand": false,
|
||||
"mounts": [
|
||||
"source=codespaces-linux-var-lib-docker,target=/var/lib/docker,type=volume"
|
||||
],
|
||||
"runArgs": [
|
||||
"--cap-add=SYS_PTRACE",
|
||||
"--security-opt",
|
||||
"seccomp=unconfined",
|
||||
"--privileged",
|
||||
"--init"
|
||||
],
|
||||
// Add the IDs of extensions you want installed when the container is created.
|
||||
"extensions": [
|
||||
"ms-azuretools.vscode-docker"
|
||||
],
|
||||
"postCreateCommand": "gh extension install github/gh-valet || echo 'Could not auto-build. Skipping.' "
|
||||
}
|
||||
"overrideCommand": false,
|
||||
"mounts": [
|
||||
"source=codespaces-linux-var-lib-docker,target=/var/lib/docker,type=volume"
|
||||
],
|
||||
"runArgs": [
|
||||
"--cap-add=SYS_PTRACE",
|
||||
"--security-opt",
|
||||
"seccomp=unconfined",
|
||||
"--privileged",
|
||||
"--init"
|
||||
],
|
||||
"remoteEnv": {
|
||||
"DOCKER_ARGS": "--network=host",
|
||||
"INSTALLATION_TYPE": "labs"
|
||||
},
|
||||
"customizations": {
|
||||
"vscode": {
|
||||
"settings": {
|
||||
"files.autoSave": "onFocusChange",
|
||||
"editor.tabSize": 2
|
||||
},
|
||||
"extensions": [
|
||||
"ms-azuretools.vscode-docker"
|
||||
]
|
||||
}
|
||||
},
|
||||
"postCreateCommand": "gh extension install github/gh-valet || echo 'Could not auto-build. Skipping.' "
|
||||
}
|
||||
+51
-39
@@ -7,50 +7,62 @@ You will need to complete all of the setup instructions [here](./readme.md#confi
|
||||
## Configuring credentials
|
||||
|
||||
1. Create an Azure DevOps personal access token (PAT).
|
||||
|
||||
__Note__: you can skip this step if you still have the PAT created during the setup steps [here](./readme.md#bootstrap-your-azure-devops-organization).
|
||||
- Navigate to your existing organization (<https://dev.azure.com/:organization>) in your browser.
|
||||
- In the top right corner of your screen, click `User settings`.
|
||||
- Click `Personal access tokens`.
|
||||
- Select `+ New Token`
|
||||
- Name your token, select the organization where you want to use the token, and set your token to automatically expire after a set number of days.
|
||||
- Select the following scopes (you may need to `Show all scopes` to reveal all scopes):
|
||||
- Agents Pool: `Read`
|
||||
- Build: `Read & execute`
|
||||
- Code: `Read & write`
|
||||
- Project and Team: `Read, write, & manage`
|
||||
- Release: `Read`
|
||||
- Service Connections: `Read`
|
||||
- Task Groups: `Read`
|
||||
- Variable Groups: `Read`
|
||||
- Click `Create`.
|
||||
- Copy the generated API token and save it in a safe location.
|
||||
__Note__: you can skip this step if you still have the PAT created during the setup steps [here](./readme.md#bootstrap-your-azure-devops-organization).
|
||||
- Navigate to your existing organization (<https://dev.azure.com/:organization>) in your browser.
|
||||
- In the top right corner of your screen, click `User settings`.
|
||||
- Click `Personal access tokens`.
|
||||
- Select `+ New Token`
|
||||
- Name your token, select the organization where you want to use the token, and set your token to automatically expire after a set number of days.
|
||||
- Select the following scopes (you may need to `Show all scopes` to reveal all scopes):
|
||||
- Agents Pool: `Read`
|
||||
- Build: `Read & execute`
|
||||
- Code: `Read & write`
|
||||
- Project and Team: `Read, write, & manage`
|
||||
- Release: `Read`
|
||||
- Service Connections: `Read`
|
||||
- Task Groups: `Read`
|
||||
- Variable Groups: `Read`
|
||||
- Click `Create`.
|
||||
- Copy the generated API token and save it in a safe location.
|
||||
|
||||
2. Create a GitHub personal access token (PAT):
|
||||
- Open github.com in a new browser tab.
|
||||
- In the top right corner of the UI, click your profile photo and then 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.
|
||||
- Name your token in the `Note` field.
|
||||
- Select the following scopes: `workflow` and `read:packages`.
|
||||
- Click `Generate token`.
|
||||
- Copy the generated PAT and save it in a safe location.
|
||||
- Open github.com in a new browser tab.
|
||||
- In the top right corner of the UI, click your profile photo and then 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.
|
||||
- Name your token in the `Note` field.
|
||||
- Select the following scopes: `workflow` and `read:packages`.
|
||||
- Click `Generate token`.
|
||||
- Copy the generated PAT and save it in a safe location.
|
||||
|
||||
3. Run the `configure` CLI command:
|
||||
- Select the `TERMINAL` tab from within the codespace terminal.
|
||||
- Run the following command: `gh valet configure`.
|
||||
- Use the down arrow key to highlight `Azure DevOps`, press the spacebar to select, and then press enter to continue.
|
||||
- At the GitHub handle prompt, enter the GitHub handle used to generate the GitHub PAT in step 2 and press enter.
|
||||
- At the GitHub Container Registry prompt, enter the GitHub PAT generated in step 2 and press enter.
|
||||
- At the GitHub PAT prompt, enter the GitHub PAT generated in step 2 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 Azure DevOps token prompt, enter the access token from step 1 and press enter.
|
||||
- At the Azure DevOps URL prompt, enter your Azure DevOps URL or press enter to accept the default value (`https://dev.azure.com`).
|
||||
- At the prompt, enter your Azure DevOps organization name. This should be the same organization used in the setup steps [here](./readme.md#bootstrap-your-azure-devops-organization).
|
||||
- At the prompt, enter your Azure DevOps project name. This should be the same project name used in the setup steps [here](./readme.md#bootstrap-your-azure-devops-organization).
|
||||
- Select the `TERMINAL` tab from within the codespace terminal.
|
||||
- Run the following command: `gh valet configure`.
|
||||
- Use the down arrow key to highlight `Azure DevOps`, press the spacebar to select, and then press enter to continue.
|
||||
- At the GitHub handle prompt, enter the GitHub handle used to generate the GitHub PAT in step 2 and press enter.
|
||||
- At the GitHub Container Registry prompt, enter the GitHub PAT generated in step 2 and press enter.
|
||||
- At the GitHub PAT prompt, enter the GitHub PAT generated in step 2 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 Azure DevOps token prompt, enter the access token from step 1 and press enter.
|
||||
- At the Azure DevOps URL prompt, enter your Azure DevOps URL or press enter to accept the default value (`https://dev.azure.com`).
|
||||
- At the prompt, enter your Azure DevOps organization name. This should be the same organization used in the setup steps [here](./readme.md#bootstrap-your-azure-devops-organization).
|
||||
- At the prompt, enter your Azure DevOps project name. This should be the same project name used in the setup steps [here](./readme.md#bootstrap-your-azure-devops-organization).
|
||||
|
||||
|
||||
```console
|
||||
$ gh valet configure
|
||||
✔ Which CI providers are you configuring?: Azure DevOps
|
||||
Enter the following values (leave empty to omit):
|
||||
✔ GitHub handle used to authenticate with the GitHub Container Registry: mona
|
||||
✔ Personal access token to authenticate with the GitHub Container Registry: ***************
|
||||
✔ Personal access token for GitHub: ***************
|
||||
✔ Base url of the GitHub instance: https://github.com
|
||||
✔ Personal access token for Azure DevOps: ***************
|
||||
✔ Base url of the Azure DevOps instance: https://dev.azure.com
|
||||
✔ Azure DevOps organization name: :organization
|
||||
✔ Azure DevOps project name: :project
|
||||
Environment variables successfully updated.
|
||||
```
|
||||
|
||||
## Verify your environment
|
||||
|
||||
|
||||
@@ -172,7 +172,7 @@ Open the workflow that is generated and inspect the contents. Now the `DotnetCor
|
||||
|
||||
You can also use custom transformers to edit the values of environment variables in converted workflows. In this example, you will be updating the `BUILDCONFIGURATION` environment variable to be `Debug` instead of `Release`.
|
||||
|
||||
To do this, add the following code to the `transformers.rb` file.
|
||||
To do this, add the following code at the top of the `transformers.rb` file.
|
||||
|
||||
```ruby
|
||||
env "BUILDCONFIGURATION", "Debug"
|
||||
|
||||
+33
-21
@@ -7,32 +7,44 @@ You will need to complete all of the setup instructions [here](./readme.md#confi
|
||||
## Configuring credentials
|
||||
|
||||
1. 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`.
|
||||
- Click `Generate token`.
|
||||
- Copy the generated PAT and save in a safe location.
|
||||
- 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`.
|
||||
- Click `Generate token`.
|
||||
- Copy the generated PAT and save in a safe location.
|
||||
|
||||
3. Create a CircleCI personal API token using CircleCI's [documentation](https://circleci.com/docs/managing-api-tokens#creating-a-personal-api-token) and store the token in a safe location.
|
||||
|
||||
2. 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 `CircleCI`, press the spacebar to select, and then hit enter to continue.
|
||||
- At the GitHub handle prompt, enter the GitHub username used to generate the GitHub PAT in step 2 and press enter.
|
||||
- At the GitHub Container Registry prompt, enter the GitHub PAT generated in step 1 and press enter.
|
||||
- At the GitHub PAT prompt, enter the GitHub PAT generated in step 1 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 CircleCI token prompt, enter the CircleCI access token from step 2 and press enter.
|
||||
- At the CircleCI base url prompt, hit enter to accept the default value (`https://circleci.com`).
|
||||
- At the CircleCI organization name prompt, enter `valet-labs`. This is the organization we'll be using throughout these labs.
|
||||
- At the access token to fetch source code in GitHub prompt, enter the GitHub PAT generated in step 1 and press enter.
|
||||
- At the GitHub instance url containing source code prompt, press enter to accept the default value (`https://github.com`).
|
||||
- Select the `TERMINAL` tab from within the codespace terminal window.
|
||||
- Run the following command: `gh valet configure`.
|
||||
- Using the down arrow key to highlight `CircleCI`, press the spacebar to select, and then hit enter to continue.
|
||||
- At the GitHub handle prompt, enter the GitHub username used to generate the GitHub PAT in step 2 and press enter.
|
||||
- At the GitHub Container Registry prompt, enter the GitHub PAT generated in step 1 and press enter.
|
||||
- At the GitHub PAT prompt, enter the GitHub PAT generated in step 1 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 CircleCI token prompt, enter the CircleCI access token from step 2 and press enter.
|
||||
- At the CircleCI base url prompt, hit enter to accept the default value (`https://circleci.com`).
|
||||
- At the CircleCI organization name prompt, enter `valet-labs`. This is the organization we'll be using throughout these labs.
|
||||
- At the access token to fetch source code in GitHub prompt, enter the GitHub PAT generated in step 1 and press enter.
|
||||
- At the GitHub instance url containing source code prompt, press enter to accept the default value (`https://github.com`).
|
||||
|
||||
|
||||
```console
|
||||
$ gh valet configure
|
||||
✔ Which CI providers are you configuring?: CircleCI
|
||||
Enter the following values (leave empty to omit):
|
||||
✔ GitHub handle used to authenticate with the GitHub Container Registry: mona
|
||||
✔ Personal access token to authenticate with the GitHub Container Registry: ***************
|
||||
✔ Personal access token for GitHub: ***************
|
||||
✔ Base url of the GitHub instance: https://github.com
|
||||
✔ Personal access token for CircleCI: ***************
|
||||
✔ Base url of the CircleCI instance: https://circleci.com
|
||||
✔ CircleCI organization name: valet-labs
|
||||
Environment variables successfully updated.
|
||||
```
|
||||
|
||||
## Verify your environment
|
||||
|
||||
|
||||
+39
-28
@@ -13,41 +13,52 @@ You will need to complete all of the setup instructions [here](./readme.md#confi
|
||||
```
|
||||
|
||||
2. Open the GitLab server in a new browser tab:
|
||||
- Click the `PORTS` tab in the codespace terminal window.
|
||||
- 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".
|
||||
- Click the `PORTS` tab in the codespace terminal window.
|
||||
- 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 (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 PAT.
|
||||
- Ensure the token has the `read_api` scope.
|
||||
- Copy the generated token and save it in a safe location.
|
||||
- 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 PAT.
|
||||
- Ensure the token has the `read_api` scope.
|
||||
- Copy the generated token and save it in a safe location.
|
||||
|
||||
4. Create a GitHub personal access token (PAT):
|
||||
- Open github.com in a new browser tab.
|
||||
- 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.
|
||||
- Name your token in the `Note` field.
|
||||
- Select the following scopes: `workflow` and `read:packages`.
|
||||
- Click `Generate token`.
|
||||
- Copy the generated PAT and save it in a safe location.
|
||||
- Open github.com in a new browser tab.
|
||||
- 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.
|
||||
- Name your token in the `Note` field.
|
||||
- Select the following scopes: `workflow` and `read:packages`.
|
||||
- Click `Generate token`.
|
||||
- Copy the generated PAT and save it in a safe location.
|
||||
|
||||
5. Run the `configure` CLI command:
|
||||
- Select the `TERMINAL` tab from within the codespace terminal window.
|
||||
- Run the following command: `gh valet configure`.
|
||||
- Use the down arrow key to highlight `GitLab CI`, press the spacebar to select, and then press enter to continue.
|
||||
- At the GitHub handle prompt, enter the GitHub handle used to generate the GitHub PAT in step 2 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.
|
||||
- Select the `TERMINAL` tab from within the codespace terminal window.
|
||||
- Run the following command: `gh valet configure`.
|
||||
- Use the down arrow key to highlight `GitLab CI`, press the spacebar to select, and then press enter to continue.
|
||||
- At the GitHub handle prompt, enter the GitHub handle used to generate the GitHub PAT in step 2 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.
|
||||
|
||||
|
||||
```console
|
||||
$ gh valet configure
|
||||
✔ Which CI providers are you configuring?: GitLab CI
|
||||
Enter the following values (leave empty to omit):
|
||||
✔ GitHub handle used to authenticate with the GitHub Container Registry: mona
|
||||
✔ Personal access token to authenticate with the GitHub Container Registry: ***************
|
||||
✔ Personal access token for GitHub: ***************
|
||||
✔ Base url of the GitHub instance: https://github.com
|
||||
✔ Private token for GitLab: ***************
|
||||
✔ Base url of the GitLab instance: https://gitlab.com
|
||||
Environment variables successfully updated.
|
||||
```
|
||||
|
||||
## Verify your environment
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@ In this lab you will build upon the `dry-run` command to override Valet's defaul
|
||||
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
|
||||
gh valet dry-run gitlab --output-dir tmp/dry-run --namespace valet --project terraform-example
|
||||
```
|
||||
|
||||
The converted workflow that is generated by the above command can be seen below:
|
||||
@@ -115,7 +115,7 @@ end
|
||||
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
|
||||
gh valet dry-run gitlab --output-dir tmp/dry-run --namespace valet --project terraform-example --custom-transformers transformers.rb
|
||||
```
|
||||
|
||||
The converted workflow that is generated by the above command will now use the custom logic for the `artifacts.terraform` step.
|
||||
@@ -131,7 +131,7 @@ The converted workflow that is generated by the above command will now use the c
|
||||
|
||||
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.
|
||||
To do this, add the following code at the top of the `transformers.rb` file.
|
||||
|
||||
```ruby
|
||||
env "PLAN_JSON", "custom_plan.json"
|
||||
|
||||
@@ -33,10 +33,6 @@ else
|
||||
docker exec -it gitlab update-permissions &> /dev/null
|
||||
fi
|
||||
|
||||
# allow valet to talk to GitLab by removing network isolation between containers
|
||||
export DOCKER_ARGS="--network=host"
|
||||
`grep -q "export DOCKER_ARGS=" ~/.bashrc || echo 'export DOCKER_ARGS="--network=host"' >> ~/.bashrc`
|
||||
|
||||
echo -e "Waiting for GitLab to be ready. This might take a while \U23F0"
|
||||
until $(curl --output /dev/null --silent --head --fail http://localhost); do
|
||||
printf '.'
|
||||
|
||||
+41
-29
@@ -7,41 +7,53 @@ You will need to complete all of the setup instructions [here](./readme.md#confi
|
||||
## Configuring credentials
|
||||
|
||||
1. Open the Jenkins server in a new browser tab:
|
||||
- Click the `PORTS` tab in the codespace terminal window.
|
||||
- In the `PORTS` tab, find the row for port 8080.
|
||||
- Hover over the address under the `Local Address` column and click the globe to "open in browser".
|
||||
- Click the `PORTS` tab in the codespace terminal window.
|
||||
- In the `PORTS` tab, find the row for port 8080.
|
||||
- Hover over the address under the `Local Address` column and click the globe to "open in browser".
|
||||
|
||||
2. Create a Jenkins API token:
|
||||
- In the top right menu bar, click the `admin` button.
|
||||
- In the left panel, click the `Configure` gear.
|
||||
- In the `API token` section, click the `Add new Token` button and click `Generate`.
|
||||
- Copy the generated API token and save it in a safe location.
|
||||
- In the top right menu bar, click the `admin` button.
|
||||
- In the left panel, click the `Configure` gear.
|
||||
- In the `API token` section, click the `Add new Token` button and click `Generate`.
|
||||
- Copy the generated API token and save it in a safe location.
|
||||
|
||||
|
||||
|
||||
|
||||
3. Create a GitHub personal access token (PAT):
|
||||
- Open github.com in a new browser tab.
|
||||
- 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 it in a safe location.
|
||||
4. Run the `configure` CLI command:
|
||||
- Select the `TERMINAL` tab from within the codespace terminal window.
|
||||
- Run the following command: `gh valet configure`.
|
||||
- Use the down arrow key to highlight `Jenkins`, press the spacebar to select, and then press enter to continue.
|
||||
- At the GitHub handle prompt, enter the GitHub username used to generate the GitHub PAT in step 3 and press enter.
|
||||
- At the GitHub Container Registry prompt, enter the GitHub PAT generated in step 3 and press enter.
|
||||
- At the GitHub PAT prompt, enter the GitHub PAT generated in step 3 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 Jenkins token prompt, enter the Jenkins access token from step 2 and press enter.
|
||||
- At the Jenkins username prompt, enter `admin` and press enter.
|
||||
- At the Jenkins URL prompt, enter `http://localhost:8080/` and press enter.
|
||||
- At the Personal access token to fetch source code in GitHub prompt, press enter to accept the default value.
|
||||
- Open github.com in a new browser tab.
|
||||
- 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 it in a safe location.
|
||||
|
||||
|
||||
4. Run the `configure` CLI command:
|
||||
- Select the `TERMINAL` tab from within the codespace terminal window.
|
||||
- Run the following command: `gh valet configure`.
|
||||
- Use the down arrow key to highlight `Jenkins`, press the spacebar to select, and then press enter to continue.
|
||||
- At the GitHub handle prompt, enter the GitHub username used to generate the GitHub PAT in step 3 and press enter.
|
||||
- At the GitHub Container Registry prompt, enter the GitHub PAT generated in step 3 and press enter.
|
||||
- At the GitHub PAT prompt, enter the GitHub PAT generated in step 3 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 Jenkins token prompt, enter the Jenkins access token from step 2 and press enter.
|
||||
- At the Jenkins username prompt, enter `admin` and press enter.
|
||||
- At the Jenkins URL prompt, enter `http://localhost:8080/` and press enter.
|
||||
|
||||
```console
|
||||
$ gh valet configure
|
||||
✔ Which CI providers are you configuring?: Jenkins
|
||||
Enter the following values (leave empty to omit):
|
||||
✔ GitHub handle used to authenticate with the GitHub Container Registry: mona
|
||||
✔ Personal access token to authenticate with the GitHub Container Registry: ***************
|
||||
✔ Personal access token for GitHub: ***************
|
||||
✔ Base url of the GitHub instance: https://github.com
|
||||
✔ Personal access token for Jenkins: ***************
|
||||
✔ Username of Jenkins user: admin
|
||||
✔ Base url of the Jenkins instance: https://localhost
|
||||
Environment variables successfully updated.
|
||||
```
|
||||
|
||||
## Verify your environment
|
||||
|
||||
|
||||
@@ -205,7 +205,7 @@ Now you can perform another `dry-run` command with the `--custom-transformers` C
|
||||
|
||||
You can also use custom transformers to edit the values of environment variables in converted workflows. In this example, you will be updating the `DB_ENGINE` environment variable to be `mongodb` instead of `sqlite`.
|
||||
|
||||
To do this, add the following code to the `transformers.rb` file.
|
||||
To do this, add the following code at the top of the `transformers.rb` file.
|
||||
|
||||
```ruby
|
||||
env "DB_ENGINE", "mongodb"
|
||||
|
||||
@@ -18,10 +18,6 @@ else
|
||||
docker run -d --name jenkins -p 8080:8080 --env JENKINS_ADMIN_ID=$username --env JENKINS_ADMIN_PASSWORD=$password jenkins:$container_name
|
||||
fi
|
||||
|
||||
# allow valet to talk to Jenkins by removing network isolation between containers
|
||||
export DOCKER_ARGS="--network=host"
|
||||
grep -q "export DOCKER_ARGS=" ~/.bashrc || echo 'export DOCKER_ARGS="--network=host"' >> ~/.bashrc
|
||||
|
||||
echo -e "\nWaiting for Jenkins to start..."
|
||||
while ! curl -s http://localhost:8080/ > /dev/null; do
|
||||
printf "."
|
||||
|
||||
@@ -12,4 +12,5 @@ To get started:
|
||||
- [Migrations from CircleCI to GitHub Actions](/circle_ci/readme.md)
|
||||
- [Migrations from GitLab CI to GitHub Actions](/gitlab/readme.md)
|
||||
- [Migrations from Jenkins to GitHub Actions](/jenkins/readme.md)
|
||||
- [Migrations from Travis CI to GitHub Actions](/travis/readme.md)
|
||||
3. Each learning path describes how to configure your codespace, bootstrap a CI/CD environment, and troubleshoot the Valet CLI.
|
||||
|
||||
@@ -0,0 +1,73 @@
|
||||
# Configure credentials for Valet
|
||||
|
||||
In this lab, you will use the `configure` CLI command to set the required credentials and information for Valet to use when working with Travis CI and GitHub.
|
||||
|
||||
You will need to complete all of the setup instructions [here](./readme.md#configure-your-codespace) prior to performing this lab.
|
||||
|
||||
## Configuring credentials
|
||||
|
||||
1. Create a GitHub personal access token (PAT):
|
||||
- Open github.com in a new browser tab.
|
||||
- In the top right corner of the UI, click your profile photo and then 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 it in a safe location.
|
||||
|
||||
3. Create a Travis CI personal access token (PAT):
|
||||
- Open app.travis-ci.com in a new browser tab.
|
||||
- Click on your profile icon in the top right hand corner to reveal a dropdown menu.
|
||||
- Click on the `Settings` tab.
|
||||
- Click on the `COPY TOKEN` button under "API authentication header" and save it in a safe location.
|
||||
|
||||
2. Run the `configure` CLI command:
|
||||
- Select the `TERMINAL` tab from within the codespace terminal.
|
||||
- Run the following command: `gh valet configure`.
|
||||
- Use the down arrow key to highlight `Travis CI`, press the spacebar to select, and then press enter to continue.
|
||||
- At the GitHub Container Registry prompt, enter the GitHub PAT generated in step 2 and press enter.
|
||||
- At the GitHub PAT prompt, enter the GitHub PAT generated in step 2 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 Travis CI token prompt, enter the Travis CI access token from step 2 and press enter.
|
||||
- At the Travis CI base url prompt, hit enter to accept the default value (`https://travis-ci.com`).
|
||||
- At the Travis CI organization name, enter `valet-labs`.
|
||||
|
||||
```console
|
||||
$ gh valet configure
|
||||
✔ Which CI providers are you configuring?: Travis CI
|
||||
Enter the following values (leave empty to omit):
|
||||
✔ GitHub handle used to authenticate with the GitHub Container Registry: mona
|
||||
✔ Personal access token to authenticate with the GitHub Container Registry: ***************
|
||||
✔ Personal access token for GitHub: ***************
|
||||
✔ Base url of the GitHub instance: https://github.com
|
||||
✔ Personal access token for Travis CI: ***************
|
||||
✔ Base url of the Travis CI instance: https://travis-ci.com
|
||||
✔ Travis CI organization name: valet-labs
|
||||
Environment variables successfully updated.
|
||||
```
|
||||
|
||||
## 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.
|
||||
|
||||
1. In the codespace terminal run the following command:
|
||||
|
||||
```bash
|
||||
gh valet update
|
||||
```
|
||||
|
||||
2. You should see a confirmation that you were logged into the GitHub Container Registry and Valet was updated to the latest version.
|
||||
|
||||
```console
|
||||
$ gh valet update
|
||||
Login Succeeded
|
||||
latest: Pulling from valet-customers/valet-cli
|
||||
Digest: sha256:a7d00dee8a37e25da59daeed44b1543f476b00fa2c41c47f48deeaf34a215bbb
|
||||
Status: Image is up to date for ghcr.io/valet-customers/valet-cli:latest
|
||||
ghcr.io/valet-customers/valet-cli:latest
|
||||
```
|
||||
|
||||
### Next lab
|
||||
|
||||
[Perform an audit of a Travis CI organization](./2-audit.md)
|
||||
@@ -0,0 +1,321 @@
|
||||
# Perform an audit of CircleCI
|
||||
|
||||
In this lab, you will use the `audit` command to get a high-level view of all projects in a Travis CI organization.
|
||||
|
||||
The `audit` command operates by performing the following:
|
||||
|
||||
- Fetching all of the projects defined in a Travis CI organization.
|
||||
- Converting each to their equivalent GitHub Actions workflow.
|
||||
- Generating a report that summarizes how complete and complex of a migration is possible with Valet.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
1. Followed the steps [here](./readme.md#configure-your-codespace) to set up your Codespace environment.
|
||||
2. Completed the [configure lab](./1-configure.md#configure-credentials-for-valet).
|
||||
|
||||
## Perform an audit
|
||||
|
||||
You will be performing an audit against the **labs-data** Travis CI organization that was created for the purposes of this lab. Your environment was configured to use this organization during the [configure lab](./1-configure.md). The remaining information needed to perform an `audit` is:
|
||||
|
||||
1. 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.
|
||||
|
||||
### Steps
|
||||
|
||||
1. Navigate to the codespace terminal.
|
||||
2. Run the following command from the root directory:
|
||||
|
||||
```bash
|
||||
gh valet audit travis-ci --output-dir tmp/audit
|
||||
```
|
||||
|
||||
3. The command will list all the files written to disk in green when the command succeeds.
|
||||
|
||||
## Inspect the output files
|
||||
|
||||
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.
|
||||
|
||||
### Review audit summary
|
||||
|
||||
#### Pipelines
|
||||
|
||||
The pipeline summary section contains high level statistics regarding the conversion rate done by Valet:
|
||||
|
||||
```md
|
||||
# Audit summary
|
||||
|
||||
Summary for [Travis CI instance](https://travis-ci.com/valet-labs)
|
||||
|
||||
- Valet version: **0.1.0.13539 (5bb6c723d6db3688ea0653e14bbf3c63df445bfc)**
|
||||
- Performed at: **9/16/22 at 20:01**
|
||||
|
||||
## Pipelines
|
||||
|
||||
Total: **5**
|
||||
|
||||
- Successful: **0 (0%)**
|
||||
- Partially successful: **5 (100%)**
|
||||
- Unsupported: **0 (0%)**
|
||||
- Failed: **0 (0%)**
|
||||
|
||||
### Job types
|
||||
|
||||
Supported: **5 (100%)**
|
||||
|
||||
- php: **1**
|
||||
- nodejs: **1**
|
||||
- ruby: **2**
|
||||
- python: **1**
|
||||
|
||||
### Build steps
|
||||
|
||||
Total: **25**
|
||||
|
||||
Known: **22 (88%)**
|
||||
|
||||
- install: **6**
|
||||
- script: **5**
|
||||
- before_script: **3**
|
||||
- rvm: **2**
|
||||
- after_deploy: **2**
|
||||
- pushover: **1**
|
||||
- irc: **1**
|
||||
- before_deploy: **1**
|
||||
- php: **1**
|
||||
|
||||
Unknown: **1 (4%)**
|
||||
|
||||
- codedeploy: **1**
|
||||
|
||||
Unsupported: **2 (8%)**
|
||||
|
||||
- sudo: **2**
|
||||
|
||||
Actions: **28**
|
||||
|
||||
- run: **17**
|
||||
- actions/checkout@v2: **6**
|
||||
- ruby/setup-ruby@v1: **2**
|
||||
- rectalogic/notify-irc@v1: **1**
|
||||
- shivammathur/setup-php@v2: **1**
|
||||
- desiderati/github-action-pushover@v1: **1**
|
||||
|
||||
### Triggers
|
||||
|
||||
Total: **30**
|
||||
|
||||
Known: **30 (100%)**
|
||||
|
||||
- crons: **5**
|
||||
- branches: **5**
|
||||
- config_validation: **5**
|
||||
- build_pull_requests: **5**
|
||||
- build_pushes: **5**
|
||||
- builds_only_with_travis_yml: **5**
|
||||
|
||||
Actions: **10**
|
||||
|
||||
- pull_request: **5**
|
||||
- push: **5**
|
||||
|
||||
### Environment
|
||||
|
||||
Total: **1**
|
||||
|
||||
Known: **1 (100%)**
|
||||
|
||||
- DB: **1**
|
||||
|
||||
Actions: **1**
|
||||
|
||||
- DB: **1**
|
||||
|
||||
### Other
|
||||
|
||||
Total: **15**
|
||||
|
||||
Known: **10 (66%)**
|
||||
|
||||
- auto_cancel_pull_requests: **5**
|
||||
- auto_cancel_pushes: **5**
|
||||
|
||||
Unknown: **5 (33%)**
|
||||
|
||||
- maximum_number_of_builds: **5**
|
||||
|
||||
Actions: **3**
|
||||
|
||||
- matrix: **2**
|
||||
- DB: **1**
|
||||
|
||||
### Manual tasks
|
||||
|
||||
Total: **1**
|
||||
|
||||
Secrets: **1**
|
||||
|
||||
- `${{ secrets.PUSHOVER_USER_KEY }}`: **1**
|
||||
|
||||
### Partially successful
|
||||
|
||||
#### valet-labs/travisci-php-example
|
||||
|
||||
- [valet-labs/travisci-php-example.yml](valet-labs/travisci-php-example.yml)
|
||||
- [valet-labs/travisci-php-example.config.json](valet-labs/travisci-php-example.config.json)
|
||||
- [valet-labs/travisci-php-example.source.yml](valet-labs/travisci-php-example.source.yml)
|
||||
|
||||
#### valet-labs/travisci-nodejs-example
|
||||
|
||||
- [valet-labs/travisci-nodejs-example.yml](valet-labs/travisci-nodejs-example.yml)
|
||||
- [valet-labs/travisci-nodejs-example.config.json](valet-labs/travisci-nodejs-example.config.json)
|
||||
- [valet-labs/travisci-nodejs-example.source.yml](valet-labs/travisci-nodejs-example.source.yml)
|
||||
|
||||
#### valet-labs/travisci-ruby-example
|
||||
|
||||
- [valet-labs/travisci-ruby-example.yml](valet-labs/travisci-ruby-example.yml)
|
||||
- [valet-labs/travisci-ruby-example.config.json](valet-labs/travisci-ruby-example.config.json)
|
||||
- [valet-labs/travisci-ruby-example.source.yml](valet-labs/travisci-ruby-example.source.yml)
|
||||
|
||||
#### valet-labs/travisci-python-example
|
||||
|
||||
- [valet-labs/travisci-python-example.yml](valet-labs/travisci-python-example.yml)
|
||||
- [valet-labs/travisci-python-example.config.json](valet-labs/travisci-python-example.config.json)
|
||||
- [valet-labs/travisci-python-example.source.yml](valet-labs/travisci-python-example.source.yml)
|
||||
|
||||
#### valet-labs/travisci-deploy-example
|
||||
|
||||
- [valet-labs/travisci-deploy-example.yml](valet-labs/travisci-deploy-example.yml)
|
||||
- [valet-labs/travisci-deploy-example.config.json](valet-labs/travisci-deploy-example.config.json)
|
||||
- [valet-labs/travisci-deploy-example.source.yml](valet-labs/travisci-deploy-example.source.yml)
|
||||
```
|
||||
|
||||
Here are some key terms that can appear in the “Pipelines” section:
|
||||
|
||||
- **Successful** pipelines had 0% of the pipeline constructs and individual items converted automatically to their GitHub Actions equivalent.
|
||||
- **Partially successful** pipelines had 100% of all of the pipeline constructs converted, however, there were some individual items that were not converted automatically to their GitHub Actions equivalent.
|
||||
- **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 Travis CI.
|
||||
- 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.
|
||||
|
||||
The "Job types" section will summarize which types of pipelines are being used and which are supported or unsupported by Valet.
|
||||
|
||||
#### Build steps
|
||||
|
||||
The build steps summary section presents an overview of the individual build steps that are used across all pipelines and how many were automatically converted by Valet.
|
||||
|
||||
```md
|
||||
Total: **25**
|
||||
|
||||
Known: **22 (88%)**
|
||||
|
||||
- install: **6**
|
||||
- script: **5**
|
||||
- before_script: **3**
|
||||
- rvm: **2**
|
||||
- after_deploy: **2**
|
||||
- pushover: **1**
|
||||
- irc: **1**
|
||||
- before_deploy: **1**
|
||||
- php: **1**
|
||||
|
||||
Unknown: **1 (4%)**
|
||||
|
||||
- codedeploy: **1**
|
||||
|
||||
Unsupported: **2 (8%)**
|
||||
|
||||
- sudo: **2**
|
||||
|
||||
Actions: **28**
|
||||
|
||||
- run: **17**
|
||||
- actions/checkout@v2: **6**
|
||||
- ruby/setup-ruby@v1: **2**
|
||||
- rectalogic/notify-irc@v1: **1**
|
||||
- shivammathur/setup-php@v2: **1**
|
||||
- desiderati/github-action-pushover@v1: **1**
|
||||
```
|
||||
|
||||
Here are some key terms that can appear in "Build steps" section:
|
||||
|
||||
- A **known** build step is a step that was automatically converted to an equivalent action.
|
||||
- An **unknown** build step is a step that was not automatically converted to an equivalent action.
|
||||
- An **unsupported** build step is a step that is either:
|
||||
- A step that is fundamentally not supported by GitHub Actions.
|
||||
- A step that is configured in a way that is incompatible with GitHub Actions.
|
||||
- An **action** is a list of the actions that were used in the converted workflows. This is important for the following scenarios:
|
||||
- Gathering the list of actions to sync to your appliance if you use GitHub Enterprise Server.
|
||||
- Defining an organization-level allowlist of actions that can be used. This list of actions is a comprehensive list of which actions their security and/or compliance teams will need to review.
|
||||
|
||||
There is an equivalent breakdown of build triggers, environment variables, and other uncategorized items displayed in the audit summary file.
|
||||
|
||||
#### Manual Tasks
|
||||
|
||||
The manual tasks summary section presents an overview of the manual tasks that you will need to perform that Valet is not able to complete automatically.
|
||||
|
||||
```md
|
||||
### Manual tasks
|
||||
|
||||
Total: **1**
|
||||
|
||||
Secrets: **1**
|
||||
|
||||
- `${{ secrets.PUSHOVER_USER_KEY }}`: **1**
|
||||
```
|
||||
|
||||
Here are some key terms that can appear in “Manual tasks” section:
|
||||
|
||||
- A **secret** refers to a repository or organization level secret that is used by the converted pipelines. These secrets will need to be created manually in Actions in order for these pipelines to function properly.
|
||||
- A **self-hosted runner** refers to a label of a runner that is referenced by a converted pipeline that is not a GitHub-hosted runner. You will need to manually define these runners in order for these pipelines to function properly.
|
||||
|
||||
#### Files
|
||||
|
||||
The final section of the audit report provides a manifest of all of the files that are written to disk during the audit. These files include:
|
||||
|
||||
```md
|
||||
### Partially successful
|
||||
|
||||
#### valet-labs/travisci-php-example
|
||||
|
||||
- [valet-labs/travisci-php-example.yml](valet-labs/travisci-php-example.yml)
|
||||
- [valet-labs/travisci-php-example.config.json](valet-labs/travisci-php-example.config.json)
|
||||
- [valet-labs/travisci-php-example.source.yml](valet-labs/travisci-php-example.source.yml)
|
||||
|
||||
#### valet-labs/travisci-nodejs-example
|
||||
|
||||
- [valet-labs/travisci-nodejs-example.yml](valet-labs/travisci-nodejs-example.yml)
|
||||
- [valet-labs/travisci-nodejs-example.config.json](valet-labs/travisci-nodejs-example.config.json)
|
||||
- [valet-labs/travisci-nodejs-example.source.yml](valet-labs/travisci-nodejs-example.source.yml)
|
||||
|
||||
#### valet-labs/travisci-ruby-example
|
||||
|
||||
- [valet-labs/travisci-ruby-example.yml](valet-labs/travisci-ruby-example.yml)
|
||||
- [valet-labs/travisci-ruby-example.config.json](valet-labs/travisci-ruby-example.config.json)
|
||||
- [valet-labs/travisci-ruby-example.source.yml](valet-labs/travisci-ruby-example.source.yml)
|
||||
|
||||
#### valet-labs/travisci-python-example
|
||||
|
||||
- [valet-labs/travisci-python-example.yml](valet-labs/travisci-python-example.yml)
|
||||
- [valet-labs/travisci-python-example.config.json](valet-labs/travisci-python-example.config.json)
|
||||
- [valet-labs/travisci-python-example.source.yml](valet-labs/travisci-python-example.source.yml)
|
||||
|
||||
#### valet-labs/travisci-deploy-example
|
||||
|
||||
- [valet-labs/travisci-deploy-example.yml](valet-labs/travisci-deploy-example.yml)
|
||||
- [valet-labs/travisci-deploy-example.config.json](valet-labs/travisci-deploy-example.config.json)
|
||||
- [valet-labs/travisci-deploy-example.source.yml](valet-labs/travisci-deploy-example.source.yml)
|
||||
```
|
||||
|
||||
Each pipeline will have a variety of files written that include:
|
||||
|
||||
- The original pipeline as it was defined in GitHub.
|
||||
- Any network responses used to convert a pipeline.
|
||||
- The converted workflow.
|
||||
- Stack traces that can used to troubleshoot a failed pipeline conversion
|
||||
|
||||
### Next lab
|
||||
|
||||
[Forecast potential build runner usage](3-forecast.md)
|
||||
@@ -0,0 +1,107 @@
|
||||
# Forecast potential build runner usage
|
||||
|
||||
In this lab you will use the `forecast` command to forecast potential GitHub Actions usage by computing metrics from completed pipeline runs in Travis CI.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
1. Followed the steps [here](./readme.md#configure-your-codespace) to set up your GitHub Codespaces environment.
|
||||
2. Completed the [configure lab](./1-configure.md#configuring-credentials).
|
||||
|
||||
## Perform a forecast
|
||||
|
||||
Answer the following questions before running the `forecast` command:
|
||||
|
||||
1. What is the date you want to start forecasting from?
|
||||
- **2022-09-02**. This date is needed as it is prior to when the bulk of builds were trigger in the demo Travis CI organization 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.
|
||||
2. Where do you want to store the results?
|
||||
- **tmp/forecast**
|
||||
|
||||
### Steps
|
||||
|
||||
1. Navigate to your codespace terminal
|
||||
2. Run the following command from the root directory:
|
||||
|
||||
```bash
|
||||
gh valet forecast travis-ci --output-dir tmp/forecast --start-date 2022-09-02
|
||||
```
|
||||
|
||||
3. The command will list all the files written to disk when the command succeeds.
|
||||
|
||||
```console
|
||||
$ gh valet forecast travis-ci --output-dir tmp/forecast --start-date 2022-09-02
|
||||
[2022-08-20 22:08:20] Logs: 'tmp/forecast/log/valet-20220916-021004.log'
|
||||
[2022-08-20 22:08:20] Forecasting 'http://travis-ci.com/valet-labs'
|
||||
[2022-08-20 22:08:20] Output file(s):
|
||||
[2022-08-20 22:08:20] tmp/forecast/jobs/09-16-2022-02-10_jobs_0.json
|
||||
[2022-08-20 22:08:20] tmp/forecast/forecast_report.md
|
||||
```
|
||||
|
||||
## Review the forecast report
|
||||
|
||||
The forecast report, logs, and completed job data will be located within the `tmp/forecast` folder.
|
||||
|
||||
1. Find the `forecast_report.md` file in the file explorer.
|
||||
2. Right-click the `forecast_report.md` file and select `Open Preview`.
|
||||
3. This file contains metrics used to forecast potential GitHub Actions usage.
|
||||
|
||||
### Total
|
||||
|
||||
The "Total" section of the forecast report contains high level statistics related to all the jobs completed after the `--start-date` CLI option:
|
||||
|
||||
```md
|
||||
- Job count: **18**
|
||||
- Pipeline count: **13**
|
||||
|
||||
- Execution time
|
||||
|
||||
- Total: **46 minutes**
|
||||
- Median: **1 minutes**
|
||||
- P90: **6 minutes**
|
||||
- Min: **0 minutes**
|
||||
- Max: **10 minutes**
|
||||
|
||||
- Queue time
|
||||
|
||||
- Median: **0 minutes**
|
||||
- P90: **0 minutes**
|
||||
- Min: **0 minutes**
|
||||
- Max: **0 minutes**
|
||||
|
||||
- Concurrent jobs
|
||||
|
||||
- Median: **0**
|
||||
- P90: **0**
|
||||
- Min: **0**
|
||||
- Max: **4**
|
||||
```
|
||||
|
||||
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. 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.
|
||||
|
||||
Additionally, these metrics are defined for each queue of runners defined in Travis CI. This is especially useful if there are a mix of hosted/self-hosted runners or high/low spec machines to see metrics specific to different types of runners.
|
||||
|
||||
## Forecasting multiple providers
|
||||
|
||||
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:
|
||||
|
||||
|
||||
|
||||
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:
|
||||
|
||||
```bash
|
||||
gh valet forecast --source-file-path tmp/**/jobs/*.json -o tmp/forecast-combined
|
||||
```
|
||||
|
||||
You can now inspect the output of the command to see a forecast report using all of the files matching the `tmp/**/jobs/*.json` pattern.
|
||||
|
||||
### Next Lab
|
||||
|
||||
[Perform a dry-run of a Travis CI pipeline](4-dry-run.md)
|
||||
@@ -0,0 +1,124 @@
|
||||
# Perform a dry-run of a TravisCI pipeline
|
||||
|
||||
In this lab you will use the `dry-run` command to convert a TravisCI pipeline to its equivalent GitHub Actions workflow.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
1. Followed the steps [here](./readme.md#configure-your-codespace) to set up your Codespace environment.
|
||||
2. Completed the [configure lab](./1-configure.md#configuring-credentials).
|
||||
3. Completed the [audit lab](./2-audit.md).
|
||||
|
||||
## Perform a dry run
|
||||
|
||||
You will be performing a dry-run against a TravisCI project. Answer the following questions before running this command:
|
||||
|
||||
1. What pipeline do you want to convert?
|
||||
- __travisci-ruby-example__. This is one of the sample projects avaiable in the TravisCI labs-data organization.
|
||||
|
||||
2. Where do you want to store the result?
|
||||
- __tmp/dry-run__. This can be any path within the working directory that Valet commands are executed from.
|
||||
|
||||
### Steps
|
||||
|
||||
1. Navigate to your codespace terminal.
|
||||
2. Run the following command from the root directory:
|
||||
|
||||
```bash
|
||||
gh valet dry-run travis-ci --travis-ci-repository "travisci-ruby-example" --output-dir tmp/dry-run
|
||||
```
|
||||
|
||||
3. The command will list all the files written to disk when the command succeeds.
|
||||
|
||||
```console
|
||||
$ gh valet dry-run travis-ci --travis-ci-repository "travisci-ruby-example" --output-dir tmp/dry-run
|
||||
[2022-09-19 19:46:03] Logs: 'tmp/dry-run/log/valet-20220919-194603.log'
|
||||
[2022-09-19 19:46:05] Output file(s):
|
||||
[2022-09-19 19:46:05] tmp/dry-run/valet-labs/travisci-ruby-example.yml
|
||||
```
|
||||
|
||||
4. View the converted workflow:
|
||||
- Find `tmp/dry-run` in the file explorer pane in your codespace.
|
||||
- Click `travisci-ruby-example.yml` to open.
|
||||
|
||||
## Inspect the output files
|
||||
|
||||
The files generated from the `dry-run` command represent the equivalent Actions workflow for the TravisCI project. The TravisCI configuration and converted workflow can be seen below:
|
||||
|
||||
<details>
|
||||
<summary><em>TravisCI configuration 👇</em></summary>
|
||||
|
||||
```yaml
|
||||
language: ruby
|
||||
sudo: false
|
||||
dist: trusty
|
||||
rvm:
|
||||
- 1.9.3
|
||||
- 2.0.0
|
||||
- 2.1.0
|
||||
|
||||
install:
|
||||
- gem install bundler
|
||||
|
||||
script:
|
||||
- echo "hello!"
|
||||
|
||||
jobs:
|
||||
include:
|
||||
- script: echo "child"
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><em>Converted workflow 👇</em></summary>
|
||||
|
||||
```yaml
|
||||
name: valet-labs/travisci-ruby-example
|
||||
on:
|
||||
push:
|
||||
branches:
|
||||
- "**/*"
|
||||
pull_request:
|
||||
concurrency:
|
||||
# # This item has no matching transformer
|
||||
# maximum_number_of_builds: 0
|
||||
jobs:
|
||||
test:
|
||||
runs-on: # this agent type is not supported: [[{"dist"=>"trusty"}]]
|
||||
ubuntu-latest
|
||||
steps:
|
||||
- name: checkout
|
||||
uses: actions/checkout@v2
|
||||
- uses: ruby/setup-ruby@v1
|
||||
with:
|
||||
ruby-version: "${{ matrix.rvm }}"
|
||||
# # 'sudo' was not transformed because there is no suitable equivalent in GitHub Actions
|
||||
- run: gem install bundler
|
||||
- run: echo "hello!"
|
||||
strategy:
|
||||
matrix:
|
||||
rvm:
|
||||
- 1.9.3
|
||||
- 2.0.0
|
||||
- 2.1.0
|
||||
test_2:
|
||||
runs-on: # this agent type is not supported: [[{"dist"=>"trusty"}]]
|
||||
ubuntu-latest
|
||||
steps:
|
||||
- name: checkout
|
||||
uses: actions/checkout@v2
|
||||
- uses: ruby/setup-ruby@v1
|
||||
with:
|
||||
ruby-version: 1.9.3
|
||||
# # 'sudo' was not transformed because there is no suitable equivalent in GitHub Actions
|
||||
- run: gem install bundler
|
||||
- run: echo "child"
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
Despite these two pipelines using different syntax they will function equivalently.
|
||||
|
||||
## Next lab
|
||||
|
||||
[Use custom transformers to customize Valet's behavior](./5-custom-transformers.md)
|
||||
@@ -0,0 +1,248 @@
|
||||
# Using custom transformers to customize Valet's behavior
|
||||
|
||||
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.
|
||||
3. Convert environment variable values differently.
|
||||
4. Convert references to runners to use a different runner name in Actions.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
1. Followed the steps [here](./readme.md#configure-your-codespace) to set up your GitHub Codespaces environment.
|
||||
2. Completed the [configure lab](./1-configure.md#configuring-credentials).
|
||||
3. Completed the [dry-run lab](./3-dry-run.md).
|
||||
|
||||
## Perform a dry-run
|
||||
|
||||
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 travis-ci --travis-ci-repository "travisci-deploy-example" --output-dir tmp/dry-run
|
||||
```
|
||||
|
||||
The converted workflow that is generated by the above command can be seen below:
|
||||
|
||||
<details>
|
||||
<summary><em>Converted workflow 👇</em></summary>
|
||||
|
||||
```yaml
|
||||
name: valet-labs/travisci-deploy-example
|
||||
on:
|
||||
push:
|
||||
branches:
|
||||
- "**/*"
|
||||
pull_request:
|
||||
concurrency:
|
||||
# # This item has no matching transformer
|
||||
# maximum_number_of_builds: 0
|
||||
env:
|
||||
DB: mysql
|
||||
jobs:
|
||||
test:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: checkout
|
||||
uses: actions/checkout@v2
|
||||
- run: gem install bundler
|
||||
- run: bundle install --jobs=3 --retry=3
|
||||
- run: rake
|
||||
- run: echo 'ready?'
|
||||
# # This item has no matching transformer
|
||||
# - codedeploy:
|
||||
# provider: codedeploy
|
||||
# access_key_id: YOUR AWS ACCESS KEY
|
||||
# secret_access_key: YOUR AWS SECRET KEY
|
||||
# bucket: S3 Bucket
|
||||
# key: latest/MyApp.zip
|
||||
# application: MyApp
|
||||
# deployment_group: MyDeploymentGroup
|
||||
# if: "${{ github.event_name == 'push' && github.ref == 'refs/heads/main' }}"
|
||||
- run: "./after_deploy_1.sh"
|
||||
- run: "./after_deploy_2.sh"
|
||||
- uses: desiderati/github-action-pushover@v1
|
||||
with:
|
||||
job-status: "${{ job.status }}"
|
||||
pushover-api-token: '12345'
|
||||
pushover-user-key: "${{ secrets.PUSHOVER_USER_KEY }}"
|
||||
if: "${{ github.event_name != 'pull_request' }}"
|
||||
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
_Note_: You can refer to the previous [lab](./3-dry-run.md) to learn about the fundamentals of the `dry-run` command.
|
||||
|
||||
## Custom transformers for an unknown step
|
||||
|
||||
The converted workflow above contains an `codedeploy` 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?
|
||||
- __codedeploy__
|
||||
|
||||
2. What is the desired Actions syntax to use instead?
|
||||
- After some research, you have determined that we can login to AWS with the `aws-actions/configure-aws-credentials@v1` action, and deploy the app to AWS using a run step to replace the functionality of `codedeploy`:
|
||||
|
||||
```yaml
|
||||
- uses: aws-actions/configure-aws-credentials@v1
|
||||
with:
|
||||
role-to-assume: owner
|
||||
role-session-name: GitHub-Action-Role
|
||||
aws-region: east-2
|
||||
- run: |
|
||||
echo "Deploying branch ${{ env.GITHUB_REF }} to ${{ github.event.inputs.environment }}"
|
||||
commit_hash=`git rev-parse HEAD`
|
||||
aws deploy create-deployment --application-name MyApp --deployment-group-name MyDeploymentGroup --github-location repository=$GITHUB_REPOSITORY,commitId=$commit_hash --ignore-application-stop-failures
|
||||
```
|
||||
|
||||
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
|
||||
touch transformers.rb && code transformers.rb
|
||||
```
|
||||
|
||||
Next, you will define a `transform` method for the `codedeploy` identifier by adding the following code to `transformers.rb`:
|
||||
|
||||
```ruby
|
||||
transform "codedeploy" do |_item|
|
||||
[
|
||||
{
|
||||
"uses" => "aws-actions/configure-aws-credentials@v1",
|
||||
"with" => {
|
||||
"role-to-assume" => "owner",
|
||||
"role-session-name" => "GitHub-Action-Role",
|
||||
"aws-region" => "east-2"
|
||||
}
|
||||
},
|
||||
{
|
||||
"run" => "echo \"Deploying branch ${{ env.GITHUB_REF }} to ${{ github.event.inputs.environment }}\"\ncommit_hash=`git rev-parse HEAD`\naws deploy create-deployment --application-name MyApp --deployment-group-name MyDeploymentGroup --github-location repository=$GITHUB_REPOSITORY,commitId=$commit_hash --ignore-application-stop-failures\n"
|
||||
}
|
||||
]
|
||||
end
|
||||
```
|
||||
|
||||
This method can use any valid ruby syntax and should return a `Hash`, or an array of `Hashes` that represent 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 Travis CI.
|
||||
|
||||
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 travis-ci --travis-ci-repository "deploy-example" --output-dir tmp/travis/dry-run --custom-transformers transformers.rb
|
||||
```
|
||||
|
||||
The converted workflow that is generated by the above command will now use the custom logic for the `codedeploy` step.
|
||||
|
||||
```diff
|
||||
- # # This item has no matching transformer
|
||||
- # - codedeploy:
|
||||
- # provider: codedeploy
|
||||
- # access_key_id: YOUR AWS ACCESS KEY
|
||||
- # secret_access_key: YOUR AWS SECRET KEY
|
||||
- # bucket: S3 Bucket
|
||||
- # key: latest/MyApp.zip
|
||||
- # application: MyApp
|
||||
- # deployment_group: MyDeploymentGroup
|
||||
- # if: "${{ github.event_name == 'push' && github.ref == 'refs/heads/main' }}"
|
||||
+ - uses: aws-actions/configure-aws-credentials@v1
|
||||
+ with:
|
||||
+ role-to-assume: owner
|
||||
+ role-session-name: GitHub-Action-Role
|
||||
+ aws-region: east-2
|
||||
+ - run: |
|
||||
+ echo "Deploying branch ${{ env.GITHUB_REF }} to ${{ github.event.inputs.environment }}"
|
||||
+ commit_hash=`git rev-parse HEAD`
|
||||
+ aws deploy create-deployment --application-name MyApp --deployment-group-name MyDeploymentGroup --github-location repository=$GITHUB_REPOSITORY,commitId=$commit_hash --ignore-application-stop-failures
|
||||
```
|
||||
|
||||
_Note_: We hard coded certain values such as the `application-name`, but we can apply these properties programmatically as well by using the item passed into the transform method. 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 "codecov_codecov_upload" do |item|
|
||||
puts item
|
||||
end
|
||||
```
|
||||
|
||||
## Custom transformers for environment variables
|
||||
|
||||
You can use custom transformers to edit the values of environment variables in converted workflows. In this example, you will update the `DB` environment variable to be `sqlite` instead of `mysql`.
|
||||
|
||||
To do this, add the following code to the `transformers.rb` file.
|
||||
|
||||
```ruby
|
||||
env "DB", "sqlite"
|
||||
```
|
||||
|
||||
In this example, the first parameter to the `env` method is the environment variable name and the second is the updated value.
|
||||
|
||||
Now you can perform another `dry-run` command with the `--custom-transformers` CLI option. When you open the converted workflow the `DB` environment variable will be set to `sqlite`:
|
||||
|
||||
```diff
|
||||
env:
|
||||
- DB: "mysql"
|
||||
+ DB: "sqlite"
|
||||
```
|
||||
|
||||
## Custom transformers for runners
|
||||
|
||||
Finally, you can use custom transformers to dictate which runners converted workflows should use. First, answer the following questions:
|
||||
|
||||
1. What is the label of the runner in Travis to update?
|
||||
- __linux__
|
||||
|
||||
2. What is the label of the runner in Actions to use instead?
|
||||
- __new-runner__
|
||||
|
||||
With these questions answered, you can add the following code to the `transformers.rb` file:
|
||||
|
||||
```ruby
|
||||
runner "linux", ["new-runner", "self-hosted"]
|
||||
```
|
||||
|
||||
In this example, the first parameter to the `runner` method is the Azure DevOps label and the second is the Actions runner labels.
|
||||
|
||||
Now you can perform another `dry-run` command with the `--custom-transformers` CLI option. When you open the converted workflow, the `runs-on` statement will use the customized runner labels:
|
||||
|
||||
```diff
|
||||
- runs-on: ubuntu-latest
|
||||
+ runs-on:
|
||||
+ - new-runner
|
||||
+ - self-hosted
|
||||
```
|
||||
|
||||
At this point, the file contents of `transformers.rb` should match this:
|
||||
|
||||
<details>
|
||||
<summary><em>Custom transformers 👇</em></summary>
|
||||
|
||||
```ruby
|
||||
transform "codedeploy" do |_item|
|
||||
[
|
||||
{
|
||||
"uses": "aws-actions/configure-aws-credentials@v1",
|
||||
"with": {
|
||||
"role-to-assume": "owner",
|
||||
"role-session-name": "GitHub-Action-Role",
|
||||
"aws-region": "east-2"
|
||||
}
|
||||
},
|
||||
{
|
||||
"run": "echo \"Deploying branch ${{ env.GITHUB_REF }} to ${{ github.event.inputs.environment }}\"\ncommit_hash=`git rev-parse HEAD`\naws deploy create-deployment --application-name MyApp --deployment-group-name MyDeploymentGroup --github-location repository=$GITHUB_REPOSITORY,commitId=$commit_hash --ignore-application-stop-failures\n"
|
||||
}
|
||||
]
|
||||
end
|
||||
|
||||
env "DB", "sqlite"
|
||||
|
||||
runner "linux", ["new-runner", "self-hosted"]
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
That's it! Congratulations, you have overridden Valet's default behavior by customizing the conversion of:
|
||||
|
||||
- Unknown steps
|
||||
- Environment variables
|
||||
- Runners
|
||||
|
||||
## Next lab
|
||||
|
||||
[Perform a production migration of a Travis CI pipeline](5-migrate.md)
|
||||
@@ -0,0 +1,55 @@
|
||||
# Perform a production migration of a Travis CI pipeline
|
||||
|
||||
In this lab, you will use the `migrate` command to convert a Travis CI pipeline and open a pull request with the equivalent Actions workflow.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
1. Followed the steps [here](./readme.md#configure-your-codespace) to set up your GitHub Codespaces environment.
|
||||
2. Completed the [configure lab](./1-configure.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
|
||||
|
||||
Answer the following questions before running a `migrate` command:
|
||||
|
||||
1. What project do you want to migrate?
|
||||
- __travisci-deploy-example__
|
||||
2. Where do you want to store the logs?
|
||||
- __./tmp/migrate__
|
||||
3. What is the URL for the GitHub repository to add the workflow to?
|
||||
- __this repository__. The URL should follow the pattern <https://github.com/:owner/:repo> with `:owner` and `:repo` replaced with your values.
|
||||
|
||||
### Steps
|
||||
|
||||
1. Run the following `migrate` command in the codespace terminal. Ensure the values in `--target-url` for `:owner` and `:repo` are replaced with your values:
|
||||
|
||||
```bash
|
||||
gh valet migrate travis-ci --target-url https://github.com/:owner/:repo --output-dir tmp/migrate --travis-ci-repository "travisci-deploy-example"
|
||||
```
|
||||
|
||||
2. The command will write the URL to the pull request that was created when the command succeeds.
|
||||
|
||||
```console
|
||||
$ gh valet migrate travis-ci --target-url https://github.com/:owner/:repo --output-dir tmp/migrate --travis-ci-repository "travisci-deploy-example"
|
||||
[2022-08-20 22:08:20] Logs: 'tmp/migrate/log/valet-20220916-014033.log'
|
||||
[2022-08-20 22:08:20] Pull request: 'https://github.com/:owner/:repo/pull/1'
|
||||
```
|
||||
|
||||
3. Open the generated pull request in a new browser tab.
|
||||
|
||||
### Inspect the pull request
|
||||
|
||||
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 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 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.
|
||||
|
||||
At this point, the migration has completed and you have successfully migrated a Travis CI pipeline to Actions!
|
||||
|
||||
## Next steps
|
||||
|
||||
This concludes all labs for migrating Travis CI pipelines to Actions with Valet!
|
||||
@@ -0,0 +1,75 @@
|
||||
# Travis CI 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 Travis CI 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.
|
||||
|
||||
## Configure your Codespace
|
||||
|
||||
1. Start a new Codespace.
|
||||
|
||||
- Click the `Code` with button down arrow above repository on the 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.
|
||||
|
||||
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:
|
||||
|
||||
```bash
|
||||
gh valet version
|
||||
```
|
||||
|
||||
- Verify the output is similar to below.
|
||||
|
||||
```console
|
||||
$ gh valet version
|
||||
gh version 2.14.3 (2022-07-26)
|
||||
gh valet github/gh-valet v0.1.12
|
||||
valet-cli unknown
|
||||
```
|
||||
|
||||
- If `gh valet version` did not produce similar output then please follow the troubleshooting [guide](#troubleshoot-the-valet-cli).
|
||||
|
||||
## Labs for Travis CI
|
||||
|
||||
Perform the following labs to test-drive Valet
|
||||
|
||||
1. [Configure credentials for Valet](1-configure.md)
|
||||
2. [Perform an audit of Travis CI](2-audit.md)
|
||||
3. [Forecast potential build runner usage](3-forecast.md)
|
||||
4. [Perform a dry-run of a Travis CI pipeline](4-dry-run.md)
|
||||
5. [Use custom transformers to customize Valet's behavior](5-custom-transformers.md)
|
||||
6. [Perform a production migration of a Travis CI pipeline](6-migrate.md)
|
||||
|
||||
## Troubleshoot the Valet CLI
|
||||
|
||||
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:
|
||||
|
||||
```bash
|
||||
gh extension install github/gh-valet
|
||||
```
|
||||
|
||||
- Verify the result of the install contains:
|
||||
|
||||
```console
|
||||
$ gh extension install github/gh-valet
|
||||
✓ 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.
|
||||
- Restart the codespace after clicking the link.
|
||||
|
||||
- Verify Valet CLI extension is installed and working by running the following command from the codespace's terminal:
|
||||
|
||||
```bash
|
||||
gh valet version
|
||||
```
|
||||
Reference in New Issue
Block a user