Adding Jenkins audit lab
This commit is contained in:
Begona Guereca
@@ -0,0 +1,114 @@
|
||||
# Audit Jenkins pipelines using the Valet audit command
|
||||
|
||||
In this lab, you will use Valet to `audit` an Azure DevOps organization. The `audit` command can be used to scan a CI server and output a summary of the current pipelines.
|
||||
|
||||
What happens behind the scenes is that Valet will perform a `dry-run` transformation on each of the Jenkins pipelines to its GitHub actions equivalent. Once that process is complete, Valet will perform an aggregation of all of these transformed workflows. This summary can be used as a planning tool and to help you understand how complete of a migration is possible with Valet.
|
||||
|
||||
- [Prerequisites](#prerequisites)
|
||||
- [Perform an audit](#perform-an-audit)
|
||||
- [View audit output](#view-audit-output)
|
||||
- [Review the pipelines](#review-the-pipelines)
|
||||
- [Next Lab](#next-lab)
|
||||
|
||||
## Prerequisites
|
||||
|
||||
1. Follow all steps [here](../jenkins#readme) to set up your environment.
|
||||
2. Follow all steps [here](../jenkins#valet_configure_lab) to finish setting up Valet.
|
||||
|
||||
## Perform an audit
|
||||
|
||||
You will use the codespace preconfigured in this repository to perform the audit.
|
||||
|
||||
1. Navigate to the codespace Visual Studio Code terminal.
|
||||
2. Verify you are in the root directory.
|
||||
3. Now, from root dirrectory, run the following Valet audit command:
|
||||
|
||||
```
|
||||
gh valet audit jenkins --output-dir tmp/audit
|
||||
```
|
||||
|
||||
4. Valet displays green log files to indicate a successful audit
|
||||
|
||||
### Example
|
||||
|
||||
|
||||
|
||||
## View audit output
|
||||
|
||||
The audit summary, logs, config files, jenkinsfiles, and transformed Actions workflows should all be located in the `tmp/audit` folder.
|
||||
|
||||
1. Under the `audit` folder find the `audit_summary.md`
|
||||
2. Right-click the `audit_summary.md` file and select `Open Preview`
|
||||
3. The file contains details about your current pipelines and what can be migrated 100% automatically vs. what will need some manual intervention or aren't supported by GitHub Actions.
|
||||
4. Review the file, it should like like the image below:
|
||||
|
||||
### Example
|
||||
|
||||
|
||||
|
||||
## Review the pipelines
|
||||
|
||||
### Pipelines
|
||||
|
||||
The audit summary starts by giving a summary of the types of pipelines that were extracted from Jenkins.
|
||||
|
||||
- It shows how there were a total of 4 pipelines extracted.
|
||||
|
||||
- 50% pipelines were successful. This means that Valet knew how to map all the constructs of the Jenkins pipeline to a GitHub Actions equivalent. So all of the build pluggins and triggers that are referenced were all successfully converted into a GitHub Actions equivalent.
|
||||
|
||||
- 50% pipelines were partially successful. That means that Valet knew how to map all the constructs of the Jenkins pipeline but there may be a plugin that is referenced that Valet doesn’t get automatically mapped to a Github Actions equivalent.
|
||||
|
||||
- 0% of these pipelines are unsupported. If there were any that would fall under this category that would mean that those pipelines are using a pipeline type that is fundamentally not supported by Valet. If there were any scripted pipelines they would appear here.
|
||||
|
||||
- 0% of these fail altogether. pipeline. If there were any pipelines that would fall under this category taht would mean that these pipelines were misconfigured or there was an issue with Valet.
|
||||
|
||||
Under the `Job types` section, we can see that the `audit` command is able to support the conversion of project, freestyle (flow-defintion), and multibranch pipelines from Jenkins and convert them to a GitHub Actions workflow. Valet does not support converting [scripted pipelines](https://www.jenkins.io/doc/book/pipeline/syntax/#scripted-pipeline) (e.g. pure Groovy).
|
||||
|
||||
#### Example
|
||||
|
||||
|
||||
|
||||
### Build steps
|
||||
|
||||
Under the `Build steps` section we can see a breakdown of the build steps that were used in these pipelines.
|
||||
|
||||
- <b>Supported:</b> 7/9 discrete build steps are considered known by Valet. When Valet encounters a build step of this type, it knows exactly how to map that into a GitHub Actions equivalent.
|
||||
- <b>Unknown:</b> 2/9 discrete build steps are considered known by Valet. When Valet enounters a build step of this type, it does not yet know to map this automatically to a GitHub Action equivalent.
|
||||
- <b>Unsupported:</b> There are currently no build steps that are unknown so this category is not shown. If there were unsupported steps, it would mean one of three things:
|
||||
1. The way that plugin was configured for a given job is unsupported.
|
||||
2. The plugin itself is fundamentally not supported in GitHub Actions.
|
||||
3. It's supported by default in GH Actions.
|
||||
|
||||
Under the `Actions` section we have the list of the actions that were used in order to implement the transformation of all of these build steps. Valet is a planning tool that can be really helpful to facilitate this migration to GitHub Actions and this list of Actions is a great place to understand what dependencies you will be taking on third-party actions after this migration.
|
||||
|
||||
So if you are doing things like setting up the allow list of third-party Actions in a GitHub Enterprise server instance this list of Actions is a fantastic place to begin security reviews and audits of what third-party actions to depend on.
|
||||
|
||||
#### Example
|
||||
|
||||
|
||||
|
||||
### Trigger, Environment, Other
|
||||
|
||||
Similar to `Build steps`, there are `Trigger`, `Environment`, a and catch all `Other` section that breakdown each of their uses accross the audited pipelines.
|
||||
|
||||
### Example
|
||||
|
||||
|
||||
|
||||
### Manual Tasks
|
||||
|
||||
Under the Manual task section you will find a list of all the manual tasks that the pipelines would surface in a migration. Manual tasks are a Valet construct that denote what `secrets` and `self-hosted` runners were referenced in the pipeline and will need to be migrated manually. We will see how these manual tasks appear on a pull request when we do a migration in a lab later on.
|
||||
|
||||
### Files
|
||||
|
||||
At the end of the Audit Summary page you will find a list of all of the files that were written to disk. Generally, for any given pipeline, you’ll find 2 or 3 associated files. In these files are the actual converted GitHub Actions workflows.
|
||||
|
||||
In addition, you’ll see a file that shows the raw JSON data that we pull from Jenkins as well as any associated Jenkinsfiles for a given job. These files are really useful for us as the engineering team to help debug any issues and to understand what may have gone on in a transformation.
|
||||
|
||||
#### Example
|
||||
|
||||
|
||||
|
||||
### Next Lab
|
||||
|
||||
[Dry run the migration of a Jenkins pipeline to GitHub Actions](valet-dry-run-lab.md)
|
||||
Reference in New Issue
Block a user