Automatically installs developer tools on a Windows machine.
The list of tools are https://github.com/juliusgb/dev-laptop-setup/blob/main/images/win/Windows2022ish-Readme.md.
That's a subset of the tools that Microsoft installs on its virtual machines on which GitHub Actions run. I wanted something similar, i.e., open a shell, execute commands to experiment without having first to worry about installing and configuring the tools/SDKs/Runtimes. That worry comes later.
I'm using release Windows Server 2022 release 20240225.2
.
But I've removed server-specific settings and tools, such as sbt
, that I'm not likely to use.
If I need the tool, I'll add the relevant Install-*
script and corresponding Pester
tests to the repo.
We need the following:
-
An internet connection that's not so firewalled. If network access is locked down via firewalls, remember to add the URLs in the
Install-*
scripts to the firewall'sallowlist
. Also keep in mind that some of these URLs get redirected. Then, add the redirects to theallowlist
. To see all redirects for a URL, use theUrlHelpers
script. -
Able to open and run PowerShell as Administrator. In it, elevate the PowerShell session's execution policy with
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope Process
-
The Packer executable. It doesn't have to be on the PATH. Download it from https://www.packer.io/downloads.
-
Winrm
has been setup and tested.Winrm
is to Windows whatssh
is to Linux. Just as Packer usesssh
to remotely manage Linux machines, so Packer useswinrm
to remotely manage Windows machines. To set upwinrm
, follow the post, https://til.juliusgamanyi.com/posts/setup-winrm
Running scripts with Administrator privileges triggers an alarm at the back of my mind. So read them, test them. And buyer beware!
To change these scripts, we need portable versions of some tools, like Packer, 7zip, vscode, git.
There's no one script (yet) to bootstrap everything. To test manually, do the following:
- Run PowerShell as Administrator: PowerShell -> Run as Admin
- Setup
winrm
. In PowerShell, run.\winrm\SetupWinRmForPacker.ps1
- Validate the packer template file with
C:\path\to\packer.exe validate packer\template.pkr.hcl
. - Add username and password in the Packer template file under
winrm-username
andwinrm-password
. - Packer build the template file with
C:\path\to\packer.exe build packer\template.pkr.hcl
. :zap: Read the section "more on step 4" :zap: - Cleanup what was added during the
winrm
setup. In PowerShell, run.\winrm\CleanupWinrmSetupForPacker.ps1
Changes to the packer template file mean re-running packer build
.
That's a once-for-all operation: there are no intermediate caches for previous steps to use again.
-
The
Install-*
scripts useChocolatey
to install the dev tools. AndChocolatey
knows whether a tool was installed. If I re-run thechoco install
step without the--force
option,Chocolatey
doesn't reinstall it. Yay, for Idempotency!! ✨ -
What's not idempotent are the directories and environment variables that were created during installation.
- That's ideal when starting from a fresh, clean machine. But have to take more care when running on my one dev machine (laptop) - no immutability.
- One way I re-test is to manually delete them before re-running
packer build
. - Another way is that when testing 2 lines, and the 2nd fails, I comment out line 1 and re-run
packer build
, which executes only line 2. That leaves the directories and env vars from line 1 untouched.
Besides keeping a subset of tooling, I've customised some to match my preferences.
-
I prefer the tooling to be installed in
C:\opt
instead ofC:\
. This meant changing related files, such as the tests and the scripts that generate the reports for the installed software. -
I've commented out some files instead of deleting them. These are for tooling that I'm likely (or would like) to use. Their corresponding tests are
skipped
. -
For tooling installed with Chocolatey, I prefer the
<package>.portable
instead of the<package>.install
versions that don't require Admin rights to install nor integration with Windows file explorer. Some Chocolatey packages allow you to change where they're installed. For these ones, I install them inC:\opt
I use thedefault
or<package>.install
version for those that need Admin rights (Git, 7zip) or that need integration with Windows File Explorer or whose installer is to cumbersome to change (CMake, AWS CLIs).
Excluded tools are those that I don't use on a day-by-day basis.
Because of excluded tooling, customized installers, I've added the -ish
suffix to the file listing the installed tooling, i.e., to Windows2022ish
.
The current version of this repo corresponds to https://github.com/actions/runner-images/releases/tag/win22%2F20240225.2.
To upgrade/update this repo to a specific released tag, I run the following manually:
- Clone the runner-images repo
- Git Checkout a specific release tag
- Run a diff on the
win
folder, especially thewin/scripts
folder. Take what changed. - Follow the steps mentioned above until step 4.
- Then test each
Install-*
one at at time.- Comment out all Packer blocks of Provisioners.
- In a particulr block, comment out all but one
Install-*
script. E.g.Install-PowerShellModules.ps1
. - Run
C:\path\to\packer.exe build packer\template.pkr.hcl
. - Fix any errors that occur.
. . .
provisioner "powershell" {
execution_policy = "unrestricted"
scripts = [
"./images/win/scripts/Installers/Install-PowerShellModules.ps1",
#"./images/win/scripts/Installers/Install-WindowsFeatures.ps1",
#"./images/win/scripts/Installers/Install-Chocolatey.ps1",
#"./images/win/scripts/Installers/Initialize-VM.ps1",
#"./images/win/scripts/Installers/Update-DotnetTLS.ps1"
]
}
# other provisioners should be commented out
- Move onto the next
Install-*
. Example below is forInstall-Chocolatey.ps1
. . .
provisioner "powershell" {
execution_policy = "unrestricted"
scripts = [
#"./images/win/scripts/Installers/Install-PowerShellModules.ps1",
#"./images/win/scripts/Installers/Install-WindowsFeatures.ps1",
"./images/win/scripts/Installers/Install-Chocolatey.ps1",
#"./images/win/scripts/Installers/Initialize-VM.ps1",
#"./images/win/scripts/Installers/Update-DotnetTLS.ps1"
]
}
# other provisioners should be commented out
- Setting up WinRM and manually testing it - https://til.juliusgamanyi.com/posts/setup-winrm
- Setup Packer with WinRM - https://til.juliusgamanyi.com/posts/packer-winrm-setup
- Use Packer to install dev tooling - https://til.juliusgamanyi.com/posts/setup-local-dev-with-packer
- Virtual machines for GitHub Actions - https://github.com/actions/runner-images
- Best script was
Configure-Toolset.ps1
. It's idempotent. It checked the directories and registry keys, deleting them, if they already exist. That made testing (i.e., re-running it) easy.