Vagrant + packer

[daxgames]

Vagrant and Packer Templates for Cmder development VMs.

Usage:

1. Clone Cmder repo to local, checkout this branch, if not yet merged.

2. Install Oracle VM Virtualbox

3. Install Vagrant

4. Install Packer if you want to do Packer template development.4.

   • Build Packer Boxes.

     • Windows

       cd %cmder_root%\scripts\packer
       .\build_windows_[10|11].bat virtualbox
       

     • Linux

       cd [CMDER Repo Folder]/scripts/packer
       ./build_windows_[10|11].sh virtualbox
       

5. Add Vagrant boxes

   • Type vagrant box add dgames\cmderdev-10
   • Type vagrant box add dgames\cmderdev-11

6. Bring up a box.

   • Type vagrant up cmderdev-10
   • Type vagrant up cmderdev-11

7. Enjoy!

What this is.

Automation to build Packer VM Images for use with Vagrant to stand up ready to use Windows VMs for Cmder Development and Testing.

Tested Virtualbox Only

• Windows 10
• Windows 11

Un-Tested Hypervisors

• VMWare Workstation
• Hyper-V
• Parallels

All VMs Stood up with Vagrant Include

• Cmder - Cloned from https://github.com/cmderdev/cmder into c:\Users\Vagrant\cmderdev
  • Added upstream remote set to https://github.com/cmderdev/cmder
• Chocolatey
  • Cmder
  • Git
  • PoshGit
  • 7zip
  • Notepad++
  • Visual Studio Community 2022
    • C++ Dev Tools for Developing Cmder Launcher.
  • Cmder Integrated Terminals
    • Tabby
    • VSCode
    • Windows Terminal
  • Other Terminals
    • Hyper
    • Fluent Terminal

Post vagrant up Config

1. Set your Cmder origin remote:

   cd %userprofile%\cmderdev
   git remote set-url origin [your fork]
   git config --global user.name "your name"
   git config --global user.email [email protected]
   

Packer Support Origins

Most of the Packer support for Cmder is shamelessly being borrowed from the following repositories and added to to support Cmder..

• StefanScherer/packer-windows
• Baune8D/packer-windows-desktop

Thank you both for the good work!

Screenshots

Windows 10 - After vagrant up

Windows 11 - With Post vagrant up user configuration.

[DRSDavidSoft]

@daxgames This is really cool and a great feature, but I was wondering whether instead of merging this branch into the master, we could use GH actions to sync it with the master, so that we can build the Vagrant releases from this branch directly? That way, we can avoid adding unnecessary files to the master branch for users/developers who don't use Vagrant.

This way we can have a /vagrant+packer branch that is automatically kept updated with master, and releases can also be created using GH actions for use on the releases page.

Users can also still use it by cloning the repo and checking out the branch. The only downside is that they need to clone the project for this, rather than downloading a ZIP source code snapshot (due to missing other branches). Still, we can provide that as a downloadable archive, as well.

Otherwise (if you don't agree with this) we can go ahead and merge this PR as is.

[daxgames]

@DRSDavidSoft Does not really matter to me, but my thought process is below.

I tried to set this up so that the zipped releases would not contain MOST of the packer/vagrant stuff.

The only new files that would be included in the release are the scripts to integrate Cmder into other terminal emulators that are also used by the vagrant/packer processes.

I am not sure I tried packaging it up, but I think it's right. If not, I can take another look.

I considered making it a completely separate repo, but I thought the scripts mentioned above could be useful to other users.

[DRSDavidSoft]

I'm sure the scripts for integrating into other terminals are useful, but I think it's better to directly commit them into master instead of merging through this branch.

That way, we can introduce a couple of other PowerShell scripts as well that were proposed before (some are present in Shark, a fork of Cmder).

So I agree with you on this point.

Personally I was working on a tweaker script to customize the prompt and the background and foreground colors for ConEmu and Windows Terminal, so maybe we could've merged it in master.

On a sidenote, would you mind if we merge our efforts so that the integration scripts you wrote and some that I was preparing would be merged in /vendor as you have prepared in this PR so those can be used both by the user and the Vagrant package as well?

Lastly, I saw the gitignore and packingore patches and you are right about the build .zip files, but the new scripts will be present in the source .zip snapshots and any clone of the repo, which was what I was initially referring to.

In any case, thanks for developing this and definitely a good job. Sorry if I made any mistakes as I'm on mobile and haven't gotten some proper sleep for the past week, I'll most definitely take an in-depth review so we can merge this PR sooner.

I apologize for the delay in responses, thanks again for the new features 👍🏻

[daxgames]

I personally don't think the extra bulk in a clone is worth having extra complexity but if the team feels that it is necessary I really don't care one way or the other

Merging efforts is fine too.

[daxgames]

@DRSDavidSoft @cmderdev/trusted-contributors I am going to backtrack on my last message. If someone is cloning or downloading a source zip I think they should get all the source.

Deployment packages should not get any of the scripts under scripts and the are not at this point.

Added complexity of having a dedicated packer/vagrant branch is not a good idea in my opinion.

I am still good with merging efforts on additional user scripts though.