forked from actions/runner-images
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Document OS and software support strategy for virtual-environments (a…
- Loading branch information
1 parent
487339f
commit b752020
Showing
9 changed files
with
70 additions
and
45 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
File renamed without changes.
54 changes: 27 additions & 27 deletions
54
help/debuggingFailedBuilds.md → docs/debugging-failed-builds.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,27 +1,27 @@ | ||
| # Debugging Failed Packer Builds | ||
|
|
||
| ## Step 1: Run packer build `-on-error=ask` | ||
| When you run the `packer build` command, give it the `-on-error=ask` flag. | ||
| By default, `packer build` will delete the resource group as soon as the build fails. | ||
| `-on-error=ask` will pause it and wait for your input so you have time to remote in to the VM and diagnose the failure. | ||
|
|
||
| When the build fails, you will see this: | ||
|
|
||
|  | ||
|
|
||
| ## Step 2: Find the resource group name in the build log | ||
| At the beginning of the build log (written to console), find the resource group name for the VM: | ||
|
|
||
|  | ||
|
|
||
| Log into the Azure Portal. Find that resource group under `Resource groups`. You should see the resources for the Packer build: | ||
|
|
||
|  | ||
|
|
||
| ## Step 3: Connect to the VM | ||
| Select the VM in the resource group. Click `Connect:` | ||
|
|
||
| This will download an RDP file. Open that and enter the credentials found in the JSON file you pass to `packer build`: | ||
|
|
||
|  | ||
|
|
||
| # Debugging Failed Packer Builds | ||
|
|
||
| ## Step 1: Run packer build `-on-error=ask` | ||
| When you run the `packer build` command, give it the `-on-error=ask` flag. | ||
| By default, `packer build` will delete the resource group as soon as the build fails. | ||
| `-on-error=ask` will pause it and wait for your input so you have time to remote in to the VM and diagnose the failure. | ||
|
|
||
| When the build fails, you will see this: | ||
|
|
||
|  | ||
|
|
||
| ## Step 2: Find the resource group name in the build log | ||
| At the beginning of the build log (written to console), find the resource group name for the VM: | ||
|
|
||
|  | ||
|
|
||
| Log into the Azure Portal. Find that resource group under `Resource groups`. You should see the resources for the Packer build: | ||
|
|
||
|  | ||
|
|
||
| ## Step 3: Connect to the VM | ||
| Select the VM in the resource group. Click `Connect:` | ||
|
|
||
| This will download an RDP file. Open that and enter the credentials found in the JSON file you pass to `packer build`: | ||
|
|
||
|  | ||
|
|
File renamed without changes
File renamed without changes
File renamed without changes
File renamed without changes
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,37 @@ | ||
| # Software and image guidelines | ||
|
|
||
| ## Software preinstallation policy | ||
| In general, these are the guidelines we consider when deciding what to pre-install: | ||
|
|
||
| - Tools and ecosystems that are broadly popular and widely-used will be given priority. | ||
| - Recent versions of tools will be given priority over older versions. | ||
| - Tools and versions that are deprecated or have reached end-of-life will not be added. | ||
| - If a tool can be installed during the build, we will evaluate how much time is saved | ||
| and how much space is used by having the tool pre-installed. | ||
| - MIT, Apache, and GNU licenses are ok, anything else we'll have to check with lawyers. | ||
| - If a tool takes much space we will evaluate space usage and provide a decision if this tool can be pre-installed. | ||
| - If a tool requires the support of more than one version, we will consider the cost of this maintenance, how often new versions bring dangerous updates. | ||
|
|
||
| **Note:** For new tools, please, create an issue and get an approval from us to add this tool to the image before creating the pull request. | ||
|
|
||
| ## Software and images support policy | ||
| These are the guidelines we follow in software and images supporting routine: | ||
| - Tools and versions will typically be removed 6 months after they are deprecated or have reached end-of-life. | ||
| - We support at least 2 latest OS versions (LTS only for Ubuntu) and initiate deprecation process for the oldest one when image usage drops below 5%. | ||
| - Most of the tools are preinstalled in the latest version only. | ||
| - Popular tools can have several versions installed side-by-side with the following strategy: | ||
|
|
||
| | Tool name | Installation strategy | | ||
| |-----------|-----------------------| | ||
| | Java | all LTS versions | | ||
| | Node.js | 3 latest LTS versions | | ||
| | Go | 3 latest minor versions | | ||
| | Python <br/> Ruby | 5 most popular `major.minor` versions | | ||
| | PyPy | 3 most popular `major.minor` versions | | ||
| | .NET Core | 2 latest LTS versions and 1 latest version. For each feature version only latest patch is installed | | ||
| | GCC <br/> GNU Fortran <br/> Clang <br/> GNU C++ | 3 latest major versions | | ||
| | Android NDK | 1 latest, 1 LTS version | | ||
| | Xcode | all OS compatible versions, latest beta for each new version | | ||
|
|
||
| ## Software default versions update policy for tools with multiple versions installed | ||
| In general, once a new version is installed on the image, we announce the default version update 2 weeks prior to deploying it to give time to adapt to upcoming changes. For potentially dangerous updates, we can extend the timeline up to 1 month between the announcement and deployment. |