Merge pull request #49 from valet-customers/Jennifer-edits
Jennifer edits
This commit is contained in:
Ethan Dennis
+31
-30
@@ -6,14 +6,15 @@ 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).
|
||||
1. __Note__: you may skip this step if you still have the PAT created during the setup steps [here](./readme.md#bootstrap-your-azure-devops-organization).
|
||||
2. Navigate to your existing organization (<https://dev.azure.com/:organization>) in your browser.
|
||||
3. Click `User settings` in the top right corner of the screen.
|
||||
4. Click `Personal access tokens`.
|
||||
5. Select `+ New Token`
|
||||
6. 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.
|
||||
7. Select the following scopes (you may need to `Show more scopes` to reveal all scopes):
|
||||
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 more scopes` to reveal all scopes):
|
||||
- Agents Pool: `Read`
|
||||
- Build: `Read & Execute`
|
||||
- Code: `Read & Write`
|
||||
@@ -22,38 +23,38 @@ You will need to complete all of the setup instructions [here](./readme.md#confi
|
||||
- Service Connections: `Read`
|
||||
- Task Groups: `Read`
|
||||
- Variable Groups: `Read`
|
||||
8. Click `Create`.
|
||||
9. Copy the generated API token and save in a safe location.
|
||||
- Click `Create`.
|
||||
- Copy the generated API token and save it in a safe location.
|
||||
|
||||
2. Create a GitHub Personal Access Token (PAT):
|
||||
1. Open github.com in a new browser tab.
|
||||
2. Click your profile photo in the top right of the UI and click `Settings`.
|
||||
3. Click on `Developer Settings` in the left hand panel.
|
||||
4. Click `Personal Access Tokens` and then `Legacy tokens` (if present).
|
||||
5. Click `Generate new token` and then `Legacy tokens`. You may be required to authenticate with GitHub during this step.
|
||||
6. Select the following scopes: `read:packages` and `workflow`.
|
||||
7. Click `Generate token`.
|
||||
8. Copy the generated PAT and save 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.
|
||||
- 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 window.
|
||||
- Select the `TERMINAL` tab from within the codespace terminal.
|
||||
- Run the following command: `gh valet configure`.
|
||||
- Using the down arrow key to highlight `Azure DevOps`, press the spacebar to select, and then hit 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 hit 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 hit 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).
|
||||
- Use the down arrow key to highlight `Azure DevOps`, 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 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).
|
||||
|
||||
|
||||
|
||||
## 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 our 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:
|
||||
1. In the codespace terminal, run the following command:
|
||||
|
||||
```bash
|
||||
gh valet update
|
||||
|
||||
+10
-10
@@ -6,21 +6,21 @@ The `audit` command operates by fetching all of the pipelines defined in an Azur
|
||||
|
||||
## Prerequisites
|
||||
|
||||
1. Followed the steps [here](./readme.md#configure-your-codespace) to set up your Codespace environment and bootstrap an Azure DevOps project.
|
||||
1. Followed the steps [here](./readme.md#configure-your-codespace) to set up your GitHub Codespaces environment and bootstrap an Azure DevOps project.
|
||||
2. Completed the [configure lab](./1-configure.md#configuring-credentials).
|
||||
|
||||
## Perform an audit
|
||||
|
||||
We will be performing an audit against the bootstrapped Azure DevOps project. We will need to answer the following questions before running this command:
|
||||
You will now perform an audit against the bootstrapped Azure DevOps project. Answer the following questions before running this command:
|
||||
|
||||
1. What is the Azure DevOps organization name that we want to audit?
|
||||
1. What is the Azure DevOps organization name that you want to audit?
|
||||
- __:organization__. This should be the same organization used in the setup steps [here](./readme.md#bootstrap-your-azure-devops-organization)
|
||||
|
||||
2. What is the Azure DevOps project name that we want to audit?
|
||||
2. What is the Azure DevOps project name that you want to audit?
|
||||
- __:project__. This should be the same project name used in the setup steps [here](./readme.md#bootstrap-your-azure-devops-organization)
|
||||
|
||||
3. 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.
|
||||
3. 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
|
||||
|
||||
@@ -31,7 +31,7 @@ We will be performing an audit against the bootstrapped Azure DevOps project. We
|
||||
gh valet audit azure-devops --output-dir tmp/audit --namespace valet
|
||||
```
|
||||
|
||||
__Note__: The Azure DevOps organization and project name can be omitted from the `audit` command as they were persisted in the `.env.local` file in the [configure lab](./1-configure.md). You can optionally provide these arguments on the command line with the `--azure-devops-organization` and `--azure-devops-project` CLI options.
|
||||
__Note__: The Azure DevOps organization and project name can be omitted from the `audit` command because they were persisted in the `.env.local` file in the [configure lab](./1-configure.md). You can optionally provide these arguments on the command line with the `--azure-devops-organization` and `--azure-devops-project` CLI options.
|
||||
|
||||
3. The command will list all the files written to disk in green when the command succeeds.
|
||||
|
||||
@@ -39,7 +39,7 @@ We will be performing an audit against the bootstrapped Azure DevOps project. We
|
||||
|
||||
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
|
||||
|
||||
@@ -73,7 +73,7 @@ Here are some key terms in the "Pipelines" section in the above example:
|
||||
- Classic (designer)
|
||||
- YAML
|
||||
- Release
|
||||
- __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 Azure DevOps.
|
||||
- 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.
|
||||
@@ -172,4 +172,4 @@ Each pipeline will have a variety of files written that include:
|
||||
|
||||
### Next lab
|
||||
|
||||
[Perform a dry-run of an Azure DevOps pipeline](3-dry-run.md)
|
||||
[Perform a dry-run migration of an Azure DevOps pipeline](3-dry-run.md)
|
||||
|
||||
@@ -1,16 +1,16 @@
|
||||
# Perform a dry-run of an Azure DevOps pipeline
|
||||
# Perform a dry-run migration of an Azure DevOps pipeline
|
||||
|
||||
In this lab you will use the `dry-run` command to convert an Azure DevOps pipeline to its equivalent GitHub Actions workflow.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
1. Followed the steps [here](./readme.md#configure-your-codespace) to set up your Codespace environment and bootstrap an Azure DevOps project.
|
||||
1. Followed the steps [here](./readme.md#configure-your-codespace) to set up your GitHub Codespaces environment and bootstrap an Azure DevOps project.
|
||||
2. Completed the [configure lab](./1-configure-lab.md#configuring-credentials).
|
||||
3. Completed the [audit lab](./2-audit.md).
|
||||
|
||||
## Perform a dry run
|
||||
|
||||
We will be performing a dry-run for a pipeline in the bootstrapped Azure DevOps project. We will need to answer the following questions before running this command:
|
||||
You will perform a dry run for a pipeline in the bootstrapped Azure DevOps project. Answer the following questions before running this command:
|
||||
|
||||
1. What is the id of the pipeline to convert?
|
||||
- __:id__. This id can be found by:
|
||||
@@ -18,12 +18,12 @@ We will be performing a dry-run for a pipeline in the bootstrapped Azure DevOps
|
||||
- Selecting the pipeline with the name "valet-pipeline1"
|
||||
- Inspecting the URL to locate the pipeline id <https://dev.azure.com/:organization/:project/_build?definitionId=:pipeline_id>
|
||||
|
||||
2. 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.
|
||||
2. 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
|
||||
@@ -32,7 +32,7 @@ We will be performing a dry-run for a pipeline in the bootstrapped Azure DevOps
|
||||
|
||||
3. The command will list all the files written to disk when the command succeeds.
|
||||
4. View the converted workflow:
|
||||
- Find `./tmp/dry-run-lab` in the file explorer pane in codespaces.
|
||||
- Find `./tmp/dry-run-lab` in the file explorer pane in your codespace.
|
||||
- Click `valet-pipeline1.yml` to open.
|
||||
|
||||
## Inspect the output files
|
||||
@@ -86,7 +86,7 @@ jobs:
|
||||
|
||||
</details>
|
||||
|
||||
Despite these 2 pipelines using different syntax they will function equivalently.
|
||||
Despite these two pipelines using different syntax they will function equivalently.
|
||||
|
||||
## Next lab
|
||||
|
||||
|
||||
@@ -9,14 +9,14 @@ 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 bootstrap an Azure DevOps project.
|
||||
1. Followed the steps [here](./readme.md#configure-your-codespace) to set up your GitHub Codespaces environment and bootstrap an Azure DevOps project.
|
||||
2. Completed the [configure lab](./1-configure-lab.md#configuring-credentials).
|
||||
3. Completed the [audit lab](./2-audit.md).
|
||||
4. Completed the [dry-run lab](./3-dry-run.md).
|
||||
|
||||
## Perform a dry run
|
||||
|
||||
We will be performing a dry-run for a pipeline in the bootstrapped Azure DevOps project. We will need to answer the following questions before running this command:
|
||||
You will perform a dry-run for a pipeline in the bootstrapped Azure DevOps project. Answer the following questions before running this command:
|
||||
|
||||
1. What is the id of the pipeline to convert?
|
||||
- __:pipeline_id__. This id can be found by:
|
||||
@@ -24,8 +24,8 @@ We will be performing a dry-run for a pipeline in the bootstrapped Azure DevOps
|
||||
- Selecting the pipeline with the name "valet-custom-transformer-example"
|
||||
- Inspecting the URL to locate the pipeline id <https://dev.azure.com/:organization/:project/_build?definitionId=:pipeline_id>
|
||||
|
||||
2. 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.
|
||||
2. 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
|
||||
|
||||
@@ -38,7 +38,7 @@ We will be performing a dry-run for a pipeline in the bootstrapped Azure DevOps
|
||||
|
||||
3. The command will list all the files written to disk when the command succeeds.
|
||||
4. View the converted workflow:
|
||||
- Find `./tmp/dry-run-lab` in the file explorer pane in codespaces.
|
||||
- Find `./tmp/dry-run-lab` in the file explorer pane in your codespace.
|
||||
- Click `valet-custom-transformer-example.yml` to open.
|
||||
|
||||
The converted workflow that is generated can be seen below:
|
||||
@@ -81,26 +81,26 @@ _Note_: You can refer to the previous [lab](./3-dry-run.md) to learn about the f
|
||||
|
||||
## Custom transformers for build steps
|
||||
|
||||
We can use custom transformers to override Valet's default behavior. In this scenario, we may want to override the behavior for converting `DotnetCoreCLI@2` tasks to support parameters that are glob patterns. We will need to answer the following questions before writing a custom transformer:
|
||||
You can use custom transformers to override Valet's default behavior. In this scenario, you may want to override the behavior for converting `DotnetCoreCLI@2` tasks to support parameters that are glob patterns. Answer the following questions before writing a custom transformer:
|
||||
|
||||
1. What is the "identifier" of the step to customize?
|
||||
- __DotnetCoreCLI@2__
|
||||
|
||||
2. What is the desired Actions syntax to use instead?
|
||||
- After some research, we have determined that the uploading test results as an artifact will be suitable:
|
||||
- After some research, you have determined that the uploading test results as an artifact will be suitable:
|
||||
|
||||
```yaml
|
||||
- run: shopt -s globstar; for f in ./**/*.csproj; do dotnet build $f --configuration ${{ env.BUILDCONFIGURATION }} ; done
|
||||
shell: bash
|
||||
```
|
||||
|
||||
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. 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:
|
||||
|
||||
```bash
|
||||
code transformers.rb
|
||||
```
|
||||
|
||||
Next, we will define a `transform` method for the `DotnetCoreCLI@2` identifier by adding the following code to `transformers.rb`:
|
||||
Next, you will define a `transform` method for the `DotnetCoreCLI@2` identifier by adding the following code to `transformers.rb`:
|
||||
|
||||
```ruby
|
||||
transform "DotNetCoreCLI@2" do |item|
|
||||
@@ -124,13 +124,13 @@ 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 Azure DevOps.
|
||||
|
||||
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 azure-devops pipeline --pipeline-id :pipeline_id -o tmp/dry-run-lab --custom-transformers transformers.rb
|
||||
```
|
||||
|
||||
Open the workflow that is generated and inspect the contents. Now, the `DotnetCoreCLI@2` steps are converted using the customized behavior!
|
||||
Open the workflow that is generated and inspect the contents. Now the `DotnetCoreCLI@2` steps are converted using the customized behavior!
|
||||
|
||||
```diff
|
||||
- - name: Restore
|
||||
@@ -147,7 +147,7 @@ Open the workflow that is generated and inspect the contents. Now, the `DotnetCo
|
||||
|
||||
## 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 `BUILDCONFIGURATION` environment variable to be `Debug` instead of `Release`.
|
||||
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.
|
||||
|
||||
@@ -157,7 +157,7 @@ env "BUILDCONFIGURATION", "Debug"
|
||||
|
||||
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 `DB_ENGINE` environment variable will be set to `mongodb`:
|
||||
Now you can perform another `dry-run` command with the `--custom-transformers` CLI option. When you open the converted workflow, the `DB_ENGINE` environment variable will be set to `mongodb`:
|
||||
|
||||
```diff
|
||||
env:
|
||||
@@ -168,7 +168,7 @@ env:
|
||||
|
||||
## Custom transformers for runners
|
||||
|
||||
Finally, we can use custom transformers to dictate which runners converted workflows should use. To do this we will need to answer the following questions:
|
||||
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 Azure DevOps to update?
|
||||
- __mechamachine__
|
||||
@@ -176,7 +176,7 @@ Finally, we can use custom transformers to dictate which runners converted workf
|
||||
2. What is the label of the runner in Actions to use instead?
|
||||
- __ubuntu-latest__
|
||||
|
||||
With these questions answered, we can add the following code to the `transformers.rb` file:
|
||||
With these questions answered, you can add the following code to the `transformers.rb` file:
|
||||
|
||||
```ruby
|
||||
runner "mechamachine", "ubuntu-latest"
|
||||
@@ -184,7 +184,7 @@ runner "mechamachine", "ubuntu-latest"
|
||||
|
||||
In this example, the first parameter to the `runner` method is the Azure DevOps label and the second is the Actions runner label.
|
||||
|
||||
Now, we 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 label:
|
||||
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 label:
|
||||
|
||||
```diff
|
||||
- runs-on:
|
||||
@@ -193,7 +193,7 @@ Now, we can perform another `dry-run` command with the `--custom-transformers` C
|
||||
+ runs-on: ubuntu-latest
|
||||
```
|
||||
|
||||
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>
|
||||
@@ -224,7 +224,7 @@ runner "mechamachine", "ubuntu-latest"
|
||||
|
||||
</details>
|
||||
|
||||
Thats it! At this point you have overridden Valet's default behavior by customizing the conversion of:
|
||||
That's it! At this point you have overridden Valet's default behavior by customizing the conversion of:
|
||||
|
||||
- Build steps
|
||||
- Environment variables
|
||||
|
||||
@@ -4,21 +4,21 @@ In this lab, you will use the `migrate` command to convert an Azure DevOps pipel
|
||||
|
||||
## Prerequisites
|
||||
|
||||
1. Followed the steps [here](./readme.md#configure-your-codespace) to set up your Codespace environment and bootstrap an Azure DevOps project.
|
||||
1. Followed the steps [here](./readme.md#configure-your-codespace) to set up your GitHub Codespaces environment and bootstrap an Azure DevOps project.
|
||||
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 id of the pipeline to convert?
|
||||
- __:pipeline_id__. This id can be found by:
|
||||
- Navigating to the build pipelines in the bootstrapped Azure DevOps project <https://dev.azure.com/:organization/:project/_build>
|
||||
- Selecting the pipeline with the name "valet-pipeline2"
|
||||
- Inspecting the URL to locate the pipeline id <https://dev.azure.com/:organization/:project/_build?definitionId=:pipeline_id>
|
||||
2. Where do we want to store the logs?
|
||||
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.
|
||||
@@ -43,13 +43,13 @@ 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 to 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.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -4,20 +4,20 @@ 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 bootstrap an Azure DevOps project.
|
||||
1. Followed the steps [here](./readme.md#configure-your-codespace) to set up your GitHub Codespaces environment and bootstrap an Azure DevOps project.
|
||||
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 is the Azure DevOps organization name that we want to audit?
|
||||
1. What is the Azure DevOps organization name that you want to audit?
|
||||
- __:organization__. This should be the same organization used in the setup steps [here](./readme.md#bootstrap-your-azure-devops-organization)
|
||||
|
||||
2. What is the Azure DevOps project name that we want to audit?
|
||||
2. What is the Azure DevOps project name that you want to audit?
|
||||
- __:project__. This should be the same project name used in the setup steps [here](./readme.md#bootstrap-your-azure-devops-organization)
|
||||
|
||||
3. Where do we want to store the results?
|
||||
3. Where do you want to store the results?
|
||||
- `./tmp/forecast_reports`
|
||||
|
||||
### Steps
|
||||
@@ -33,7 +33,7 @@ We will need to answer the following questions before running the `forecast` com
|
||||
|
||||
|
||||
|
||||
4. If you inspect the help menu using the `gh valet forecast --help` command then you will see a `--source-file-path` option. This option can be used to perform a `forecast` command using json files that are already present on the filesystem. These labs come bundled with sample json files located [here](./bootstrap/jobs.json).
|
||||
4. If you inspect the help menu using the `gh valet forecast --help` command, you will see a `--source-file-path` option. You can use this option to perform a `forecast` command using json files that are already present on the filesystem. These labs come bundled with sample json files located [here](./bootstrap/jobs.json).
|
||||
|
||||
|
||||
|
||||
@@ -91,7 +91,7 @@ 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.
|
||||
- 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.
|
||||
|
||||
|
||||
+15
-15
@@ -1,25 +1,25 @@
|
||||
# Azure Pipelines to Actions migrations powered by Valet
|
||||
|
||||
The instructions below will guide you through configuring a Codespace that will be used in these labs to demonstrate how Valet can be used to migrate Azure DevOps pipelines to GitHub Actions.
|
||||
These instructions will guide you through configuring the GitHub Codespaces environment that will be used in these labs to demonstrate how to use Valet to migrate Azure DevOps 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 a new 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,14 +33,14 @@ 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 your Azure DevOps organization
|
||||
|
||||
1. Create an Azure DevOps personal access token:
|
||||
1. Create an Azure DevOps personal access token (PAT):
|
||||
|
||||
- Navigate to your existing organization (<https://dev.azure.com/:organization>) in your browser.
|
||||
- Click `User settings` in the top right corner of the screen.
|
||||
- In the top right corner of the 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.
|
||||
@@ -54,11 +54,11 @@ These steps **must** be completed prior to starting other labs.
|
||||
- Task Groups: `Read`
|
||||
- Variable Groups: `Read`
|
||||
- Click `Create`.
|
||||
- Copy the generated API token and save in a safe location.
|
||||
- Copy the generated API token and save it in a safe location.
|
||||
|
||||
2. Execute the Azure DevOps setup script that will create a new Azure DevOps project in your organization to be used in the following labs. This script should only be run once.
|
||||
|
||||
- Run the following command from the codespace's terminal, replacing the values accordingly:
|
||||
- Run the following command from the codespace terminal, replacing the values accordingly:
|
||||
- `:organization`: the name of your existing Azure DevOps organization
|
||||
- `:project`: the name of the project to be created in your Azure DevOps organization
|
||||
- `:access_token`: the PAT created in step 1 above
|
||||
@@ -77,7 +77,7 @@ Perform the following labs to learn how to migrate Azure DevOps pipelines to Git
|
||||
|
||||
1. [Configure credentials for Valet](1-configure.md)
|
||||
2. [Perform an audit of an Azure DevOps project](2-audit.md)
|
||||
3. [Perform a dry-run of a Azure DevOps pipeline](3-dry-run.md)
|
||||
3. [Perform a dry-run migration of an Azure DevOps 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 Azure DevOps pipeline](5-migrate.md)
|
||||
6. [Forecast potential build runner usage](6-forecast.md)
|
||||
@@ -87,7 +87,7 @@ Perform the following labs to learn how to migrate Azure DevOps pipelines to Git
|
||||
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
|
||||
@@ -99,10 +99,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.
|
||||
|
||||
- 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
|
||||
|
||||
+20
-20
@@ -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.
|
||||
|
||||
|
||||
|
||||
## 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:
|
||||
|
||||
|
||||
+10
-10
@@ -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)
|
||||
|
||||
+11
-11
@@ -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
|
||||
|
||||
|
||||
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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
+7
-7
@@ -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.
|
||||
|
||||
|
||||
|
||||
|
||||
+10
-10
@@ -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:
|
||||
|
||||
|
||||
|
||||
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:
|
||||
|
||||
|
||||
+14
-14
@@ -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.
|
||||
|
||||
- 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
|
||||
|
||||
+25
-25
@@ -7,44 +7,44 @@ 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:
|
||||
1. Click the `PORTS` tab in the codespace terminal window.
|
||||
2. In the `PORTS` tab find the row for port 8080.
|
||||
3. 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:
|
||||
1. Click the `admin` button in the top right menu bar.
|
||||
2. Click on the `Configure` gear located on the left hand panel.
|
||||
3. Click the `Add new Token` button in the `API token` section and click `Generate`.
|
||||
4. Copy the generated API token and save 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):
|
||||
1. Open github.com in a new browser tab.
|
||||
2. Click your profile photo in the top right of the UI and click `Settings`.
|
||||
3. Click on `Developer Settings` in the left hand panel.
|
||||
4. Click `Personal Access Tokens` and then `Legacy tokens` (if present).
|
||||
5. Click `Generate new token` and then `Legacy tokens`. You may be required to authenticate with GitHub during this step.
|
||||
6. Select the following scopes: `read:packages` and `workflow`.
|
||||
7. Click `Generate token`.
|
||||
8. Copy the generated PAT and save 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`.
|
||||
- Using the down arrow key to highlight `Jenkins`, 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 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 hit 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 url prompt enter `http://localhost:8080/` and press enter.
|
||||
- At the Personal access token to fetch source code in GitHub prompt hit enter to accept the default value.
|
||||
- Use the down arrow key to highlight `Jenkins`, 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 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 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.
|
||||
|
||||
|
||||
|
||||
## 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:
|
||||
|
||||
|
||||
+8
-8
@@ -6,18 +6,18 @@ The `audit` command operates by fetching all of the pipelines defined in a Jenki
|
||||
|
||||
## Prerequisites
|
||||
|
||||
1. Followed the steps [here](./readme.md#configure-your-codespace) to set up your Codespace environment and start a Jenkins server.
|
||||
1. Followed the steps [here](./readme.md#configure-your-codespace) to set up your GitHub Codespaces environment and start a Jenkins server.
|
||||
2. Completed the [configure lab](./1-configure.md#configuring-credentials).
|
||||
|
||||
## Perform an audit
|
||||
|
||||
We will be performing an audit against your preconfigured Jenkins server. We will need to answer the following questions before running this command:
|
||||
You will be performing an audit against your preconfigured Jenkins server. Answer the following questions before running this command:
|
||||
|
||||
1. Do we want to audit the entire Jenkins instance or just a single folder?
|
||||
- In this example we will be auditing the entire Jenkins instance, but in the future if you wanted to configure a specific folder to be audited add the `-f <folder_path>` flag to the audit command.
|
||||
1. Do you want to audit the entire Jenkins instance or just a single folder?
|
||||
- In this example you will audit the entire Jenkins instance, but in the future if you wanted to configure a specific folder to be audited add the `-f <folder_path>` flag 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
|
||||
|
||||
@@ -56,7 +56,7 @@ Here are some key terms in the “Pipelines” section in the above example:
|
||||
- Flow Definition
|
||||
- Project (declarative Jenkinsfile pipelines)
|
||||
- Multibranch Project
|
||||
- __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 Jenkins.
|
||||
- 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.
|
||||
@@ -108,4 +108,4 @@ Each pipeline will have a variety of files written that include:
|
||||
|
||||
## Next lab
|
||||
|
||||
[Perform a dry-run of a Jenkins pipeline](3-dry-run.md)
|
||||
[Perform a dry-run migration of a Jenkins pipeline](3-dry-run.md)
|
||||
|
||||
+13
-13
@@ -1,29 +1,29 @@
|
||||
# Perform a dry-run of a Jenkins pipeline
|
||||
# Perform a dry-run migration of a Jenkins pipeline
|
||||
|
||||
In this lab you will use the `dry-run` command to convert a Jenkins pipeline to its equivalent GitHub Actions workflow.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
1. Followed the steps [here](./readme.md#configure-your-codespace) to set up your Codespace environment and start a Jenkins server.
|
||||
1. Followed the steps [here](./readme.md#configure-your-codespace) to set up your GitHub Codespaces environment and start a Jenkins server.
|
||||
2. Completed the [configure lab](./1-configure-lab.md#configuring-credentials).
|
||||
3. Completed the [audit lab](./2-audit.md).
|
||||
|
||||
## Perform a dry-run
|
||||
## Perform a dry run
|
||||
|
||||
We will be performing a dry-run against a pipeline in your preconfigured Jenkins 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 Jenkins server. Answer the following questions before running this command:
|
||||
|
||||
1. What is the name of the pipeline we want to convert?
|
||||
1. What is the name of the pipeline you want to convert?
|
||||
- __test_pipeline__
|
||||
|
||||
2. What is the URL of the pipeline we want to convert?
|
||||
2. What is the URL of the pipeline you want to convert?
|
||||
- __<http://localhost:8080/job/test_pipeline>__
|
||||
|
||||
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 Jenkins
|
||||
|
||||
|
||||
4. View the converted workflow:
|
||||
- Find `./tmp/dry-run` in the file explorer pane in codespaces.
|
||||
- Find `./tmp/dry-run` in the file explorer pane in your codespace.
|
||||
- Click `test_pipeline.yml` to open
|
||||
|
||||
## Inspect the output files
|
||||
@@ -123,7 +123,7 @@ jobs:
|
||||
|
||||
</details>
|
||||
|
||||
These 2 pipelines function equivalently despite using different syntax. In this case, the pipeline conversion was “partially successful” (i.e. there were item(s) not automatically converted) and the unconverted item was placed as comment in the location the Jenkins pipeline used it. For example:
|
||||
These two pipelines function equivalently despite using different syntax. In this case, the pipeline conversion was “partially successful” (i.e. there were item(s) not automatically converted) and the unconverted item was placed as comment in the location the Jenkins pipeline used it. For example:
|
||||
|
||||
```diff
|
||||
- sleep 80
|
||||
@@ -135,9 +135,9 @@ These 2 pipelines function equivalently despite using different syntax. In this
|
||||
+ # value: 80
|
||||
```
|
||||
|
||||
In the next lab, we'll learn how to override Valet's default behavior and customize the converted workflow that is generate.
|
||||
In the next lab, you'll learn how to override Valet's default behavior and customize the converted workflow that is generated.
|
||||
|
||||
Try running the `dry-run` command for different pipelines in the Jenkins server. As a hint, you just have to change the `--source-url` CLI option.
|
||||
Try running the `dry-run` command for different pipelines in the Jenkins server. As a hint, you only have to change the `--source-url` CLI option.
|
||||
|
||||
## Next lab
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Use 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 a Jenkins server.
|
||||
1. Followed the steps [here](./readme.md#configure-your-codespace) to set up your GitHub Codespaces environment and start a Jenkins 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 jenkins --source-url http://localhost:8080/job/test_pipeline -o tmp/jenkins/dry-run
|
||||
@@ -75,13 +75,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 a `sleep` step was not automatically converted. We will need to answer the following questions before writing a custom transformer:
|
||||
The converted workflow above contains a `sleep` step was not automatically converted. Answer the following questions before writing a custom transformer:
|
||||
|
||||
1. What is the "identifier" of the step to customize?
|
||||
- __sleep__. The identifier will be the key of a key value pair within the step of a Jenkinsfile.
|
||||
|
||||
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
|
||||
- name: Sleep for 80 seconds
|
||||
@@ -89,13 +89,13 @@ The converted workflow above contains a `sleep` step was not automatically conve
|
||||
shell: bash
|
||||
```
|
||||
|
||||
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 `sleep` identifier by adding the following code to `transformers.rb`:
|
||||
Next, you will define a `transform` method for the `sleep` identifier by adding the following code to `transformers.rb`:
|
||||
|
||||
```ruby
|
||||
transform "sleep" do |item|
|
||||
@@ -111,13 +111,13 @@ 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 Jenkins.
|
||||
|
||||
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 jenkins --source-url http://localhost:8080/job/test_pipeline -o tmp/jenkins/dry-run --custom-transformers transformers.rb
|
||||
```
|
||||
|
||||
Open the workflow that is generated and inspect the contents. Now, the `sleep` step is converted and uses the customized behavior!
|
||||
Open the workflow that is generated and inspect the contents. Now the `sleep` step is converted and uses the customized behavior!
|
||||
|
||||
```diff
|
||||
- # # This item has no matching transformer
|
||||
@@ -133,13 +133,13 @@ Open the workflow that is generated and inspect the contents. Now, the `sleep` s
|
||||
|
||||
## Custom transformers for a known step
|
||||
|
||||
We can also override Valet's default behavior. In this scenario, we may not desire to use the third-party action for publishing junit test results that is used by default. Again, we will need to answer the following questions before writing a custom transformer:
|
||||
You can also override Valet's default behavior. In this scenario, you may not want to use the third-party action for publishing junit test results that is used by default. Again, answer the following questions before writing a custom transformer:
|
||||
|
||||
1. What is the "identifier" of the step to customize?
|
||||
- __junit__
|
||||
|
||||
2. What is the desired Actions syntax to use instead?
|
||||
- After some research, we have determined that uploading test results as an artifact will be suitable:
|
||||
- After some research, you have determined that uploading test results as an artifact will be suitable:
|
||||
|
||||
```yaml
|
||||
- uses: actions/upload-artifact@v3
|
||||
@@ -148,9 +148,9 @@ We can also override Valet's default behavior. In this scenario, we may not desi
|
||||
path: path/to/artifact/world.txt
|
||||
```
|
||||
|
||||
We will build this custom transformer similar to the previous custom transformer, however, we first need to inspect the `item` keyword to programmatically use the file path to junit's test results in the `actions/upload-artifact@v3` step.
|
||||
You will build this custom transformer similar to the previous custom transformer, however, you first need to inspect the `item` keyword to programmatically use the file path to junit's test results in the `actions/upload-artifact@v3` step.
|
||||
|
||||
To do this, we will print `item` to the console. You can achieve this by adding the following custom transformer to `transformers.rb`:
|
||||
To do this, you will print `item` to the console. You can achieve this by adding the following custom transformer to `transformers.rb`:
|
||||
|
||||
```ruby
|
||||
transform "junit" do |item|
|
||||
@@ -162,7 +162,7 @@ Now, we can perform another `dry-run` command with the `--custom-transformers` C
|
||||
|
||||
|
||||
|
||||
Now that we know the data structure of `item` we can access the file path programmatically by editing the custom transformer to following:
|
||||
Now that you know the data structure of `item`, you can access the file path programmatically by editing the custom transformer to the following:
|
||||
|
||||
```ruby
|
||||
transform "junit" do |item|
|
||||
@@ -181,7 +181,7 @@ end
|
||||
|
||||
_Note_: `transformers.rb` should contain a `transform` method for both `sleep` and `junit`.
|
||||
|
||||
Now, we can perform another `dry-run` command with the `--custom-transformers` CLI option. When you open the converted workflow the `EnricoMi/publish-unit-test-result-action@v1.7` action will have been replaced with the customized steps.
|
||||
Now you can perform another `dry-run` command with the `--custom-transformers` CLI option. When you open the converted workflow the `EnricoMi/publish-unit-test-result-action@v1.7` action will have been replaced with the customized steps.
|
||||
|
||||
```diff
|
||||
- - name: Publish test results
|
||||
@@ -197,7 +197,7 @@ Now, we can perform another `dry-run` command with the `--custom-transformers` C
|
||||
|
||||
## 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 `DB_ENGINE` environment variable to be `mongodb` instead of `sqlite`.
|
||||
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.
|
||||
|
||||
@@ -207,7 +207,7 @@ env "DB_ENGINE", "mongodb"
|
||||
|
||||
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 `DB_ENGINE` environment variable will be set to `mongodb`:
|
||||
Now you can perform another `dry-run` command with the `--custom-transformers` CLI option. When you open the converted workflow the `DB_ENGINE` environment variable will be set to `mongodb`:
|
||||
|
||||
```diff
|
||||
env:
|
||||
@@ -218,7 +218,7 @@ env:
|
||||
|
||||
## Custom transformers for runners
|
||||
|
||||
Finally, we can use custom transformers to dictate which runners converted workflows should use. To do this we will need to answer the following questions:
|
||||
Finally, you can use custom transformers to dictate which runners the converted workflows should use. To do this, answer the following questions:
|
||||
|
||||
1. What is label of the runner in Jenkins to update?
|
||||
- __TeamARunner__
|
||||
@@ -226,7 +226,7 @@ Finally, we can use custom transformers to dictate which runners converted workf
|
||||
2. What is the label of the runner in Actions to use instead?
|
||||
- __ubuntu-latest__
|
||||
|
||||
With these questions answered, we can add the following code to the `transformers.rb` file:
|
||||
With these questions answered, you can add the following code to the `transformers.rb` file:
|
||||
|
||||
```ruby
|
||||
runner "TeamARunner", "ubuntu-latest"
|
||||
@@ -234,7 +234,7 @@ runner "TeamARunner", "ubuntu-latest"
|
||||
|
||||
In this example, the first parameter to the `runner` method is the Jenkins label and the second is the Actions runner label.
|
||||
|
||||
Now, we 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 label:
|
||||
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 label:
|
||||
|
||||
```diff
|
||||
runs-on:
|
||||
@@ -243,7 +243,7 @@ runs-on:
|
||||
+ - ubuntu-latest
|
||||
```
|
||||
|
||||
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>
|
||||
@@ -281,7 +281,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
|
||||
- Known steps
|
||||
|
||||
@@ -4,25 +4,25 @@ In this lab, you will use the `migrate` command to convert a Jenkins pipeline an
|
||||
|
||||
## Prerequisites
|
||||
|
||||
1. Followed the steps [here](./readme.md#configure-your-codespace) to set up your Codespace environment and start a Jenkins server.
|
||||
1. Followed the steps [here](./readme.md#configure-your-codespace) to set up your GitHub Codespaces environment and start a Jenkins 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 source URL of the pipeline we want to convert?
|
||||
1. What is the source URL of the pipeline you want to convert?
|
||||
- __<http://localhost:8080/monas_dev_work/job/monas_freestyle>__
|
||||
2. Where do we want to store the logs?
|
||||
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:
|
||||
1. Run the following `migrate` command in your codespace terminal:
|
||||
|
||||
```bash
|
||||
gh valet migrate jenkins --target-url https://github.com/:owner/:repo --output-dir ./tmp/migrate --source-url http://localhost:8080/job/monas_dev_work/job/monas_freestyle
|
||||
@@ -36,15 +36,15 @@ 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 we should notice about the pull request is that there is a list of manual steps to complete:
|
||||
|
||||
|
||||
|
||||
Next, let's review the workflow we are adding by clicking on `Files changed` tab. This is where you would double check everything looks good. If it didn't you could push commits with the required changes, prior to merging.
|
||||
Next, review the workflow you are adding by clicking on the `Files changed` tab. This is where you double check that everything looks good. If it didn't, you could push commits with the required changes, prior to merging.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
||||
+11
-11
@@ -4,25 +4,25 @@ 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 Jenkins server.
|
||||
1. Followed the steps [here](./readme.md#configure-your-codespace) to set up your GitHub Codespaces environment and start a Jenkins 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. Do we want to forecast the entire Jenkins server or a single folder?
|
||||
- We will be forecasting the entire Jenkins server but we could optionally limit this by using the `-f <folder_path>` CLI option.
|
||||
1. Do you want to forecast the entire Jenkins server or a single folder?
|
||||
- You will be forecasting the entire Jenkins server but you could optionally limit this by using the `-f <folder_path>` CLI option.
|
||||
|
||||
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 Jenkins 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
|
||||
@@ -76,8 +76,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.
|
||||
|
||||
@@ -85,11 +85,11 @@ Additionally, these metrics are defined for each queue of runners defined in Jen
|
||||
|
||||
## 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:
|
||||
|
||||
|
||||
|
||||
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 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`).
|
||||
|
||||
Run the following command from within the codespace terminal:
|
||||
|
||||
|
||||
+13
-13
@@ -1,6 +1,6 @@
|
||||
# Jenkins 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 Jenkins pipelines to GitHub Actions.
|
||||
These instructions will guide you through configuring a GitHub Codespaces environment that will be used in subsequent labs that demonstrate how to use Valet to migrate Jenkins pipelines to GitHub Actions.
|
||||
|
||||
These steps **must** be completed prior to starting other labs.
|
||||
|
||||
@@ -8,14 +8,14 @@ These steps **must** be completed prior to starting other 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
|
||||
## Configure your codespace
|
||||
|
||||
1. Start a new 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).
|
||||
|
||||
@@ -33,11 +33,11 @@ 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, refer to the troubleshooting [guide](#troubleshoot-the-valet-cli).
|
||||
|
||||
## Bootstrap a Jenkins server
|
||||
|
||||
1. Execute the Jenkins setup script that will start a container with a Jenkins server running inside of it. This script should be executed when starting a new Codespace or restarting an existing one.
|
||||
1. Execute the Jenkins setup script that will start a container with a Jenkins server running inside of it. This script should be executed when starting a new codespace or restarting an existing one.
|
||||
|
||||
- Run the following command from the codespace's terminal to start a Jenkins server:
|
||||
|
||||
@@ -46,7 +46,7 @@ These steps **must** be completed prior to starting other labs.
|
||||
```
|
||||
|
||||
- After some time, a pop-up box should appear with a link to the URL for your Jenkins 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 Jenkins 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 of a Jenkins server](2-audit.md)
|
||||
3. [Perform a dry-run of a Jenkins pipeline](3-dry-run.md)
|
||||
3. [Perform a dry-run migration of a Jenkins 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 Jenkins 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
|
||||
@@ -86,7 +86,7 @@ The CLI extension for Valet can be manually installed by following these steps:
|
||||
- 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:
|
||||
- Verify Valet CLI extension is installed and working by running the following command from the codespace terminal:
|
||||
|
||||
```bash
|
||||
gh valet version
|
||||
@@ -96,10 +96,10 @@ The CLI extension for Valet can be manually installed by following these steps:
|
||||
|
||||
Follow these steps if the Jenkins server does not start correctly after running the setup script:
|
||||
|
||||
1. Navigate to the `Docker` tab on the left side of the codespace.
|
||||
1. On the left side of the codespace, navigate to the `Docker` tab.
|
||||
2. Under the `Containers` tab you should see a docker container named `jenkins:valet` listed with a green play button ▶
|
||||
|
||||
- If you see the `jenkins:valet` container, but it has a red stopped symbol next to it ▢, right click on the container and click on `start`, the container should begin running again.
|
||||
- If the container does not start even after trying to manually start it, right click on the `jenkins:valet` container and click the `remove` button. Then, attempt to start the Jenkins server again by following the steps [here](#bootstrap-a-jenkins-server).
|
||||
- If you see the `jenkins:valet` container, but it has a red stopped symbol next to it ▢, right-click the container and click `start`. The container should begin running again.
|
||||
- If the container does not start even after trying to start it manually, right-click the `jenkins:valet` container and click the `remove` button. Then, attempt to start the Jenkins server again by following the steps [here](#bootstrap-a-jenkins-server).
|
||||
|
||||
|
||||
|
||||
@@ -1,15 +1,14 @@
|
||||
# GitHub Actions migrations powered by Valet
|
||||
|
||||
Valet helps facilitate the migration of Azure DevOps, CircleCI, GitLab CI, Jenkins, and Travis CI pipelines to GitHub Actions. This repository contains learning paths that teach you how to use Valet and approach migrations to Actions.
|
||||
Valet helps facilitate the migration of Azure DevOps, CircleCI, GitLab CI, Jenkins, and Travis CI pipelines to GitHub Actions. This repository contains learning paths that teach you how to use Valet and how to approach migrations to Actions.
|
||||
|
||||
> Valet is currently private and you must be onboarded prior to using it. Please reach out to [GitHub Sales](https://github.com/enterprise/contact) to inquire about being granted access.
|
||||
|
||||
To get started:
|
||||
|
||||
1. Use the `valet-customers/labs` repository as a template to [generate](https://github.com/valet-customers/labs/generate) a new GitHub repository.
|
||||
2. Select which learning path to begin. There are currently learning paths for:
|
||||
- [Azure DevOps to GitHub Actions migrations](/azure_devops/readme.md)
|
||||
- [GitLab CI to GitHub Actions migrations](/gitlab/readme.md)
|
||||
- [Jenkins to GitHub Actions migrations](/jenkins/readme.md)
|
||||
3. Follow the instructions in each learning path to bootstrap a CI/CD environment.
|
||||
4. Follow the instructions to complete each learning path.
|
||||
2. Select which learning path to begin with. There are currently learning paths for:
|
||||
- [Migrations from Azure DevOps to GitHub Actions](/azure_devops/readme.md)
|
||||
- [Migrations from GitLab CI to GitHub Actions](/gitlab/readme.md)
|
||||
- [Migrations from Jenkins to GitHub Actions](/jenkins/readme.md)
|
||||
3. Each learning path describes how to configure your codespace, bootstrap a CI/CD environment, and troubleshoot the Valet CLI.
|
||||
|
||||
Reference in New Issue
Block a user