refactoring

[majkinetor]

I changed the vagrant so that no changes to it are necessary.

I moved inline script to scripts folder and named it TestPackage. It now contains logic to look for nupkg files in the c:\packages folder for local source and c:\packages\remote for remote source.

So working with this now requires only to copy files to packages without any other action.

[ferventcoder]

This assumes one package in the folder. I will need to think on this a bit as it is not typically how I use the environment (although many others probably would).

[majkinetor]

This assumes one package in the folder. I will need to think on this a bit as it is not typically how I use the environment (although many others probably would).

So how do you use it ? I planned to integrate it with AU's Test-Package so that when you call something like Test-Package -Vagrant it will copy the files there and run the machine.

But anway, just say how u use it so I can make it work for all of us.

[ferventcoder]

But anway, just say how u use it so I can make it work for all of us.

That's why the think on this...

[majkinetor]

That's why the think on this...

You didn't answer me how you use it. If you do, maybe we can both think about solution ?

[ferventcoder]

You didn't answer me how you use it. If you do, maybe we can both think about solution ?

In lots of ways.

• Sometimes to test a simple package for folks (remote package, no copy local first).
• Also for testing new Chocolatey releases/betas (keep in mind the packages folder may have a ton of different versions of the same package in it for me).
• Testing different scenarios with Chocolatey.

I like that the Vagrantfile allows for me to specify as few or as many files to test as I want.

[ferventcoder]

I planned to integrate it with AU's Test-Package so that when you call something like Test-Package -Vagrant it will copy the files there and run the machine.

We can definitely get it set up for that scenario as well. Perhaps a new folder where it will just look and install the packages in that folder automatically.

[majkinetor]

Sometimes to test a simple package for folks (remote package, no copy local first).

I see, we could solve that with either vagrant argument or env var that contains package name, in which case c:\packages folder wouldn't get read.

So, one of those 2

  $env:package = 'copyq'; vagrant up --provision
  vagrant up --provision --package copyq

TBH, I think the second one is not as easy to implement (at least it wasn't when I was a lot into vagrant a year before) but its doable. I think first one is probably the best.

Also for testing new Chocolatey releases/betas (keep in mind the packages folder may have a ton of different versions of the same package in it for me). ... I like that the Vagrantfile allows for me to specify as few or as many files to test as I want.

Installing each package is a trivial change I can add it.

[majkinetor]

Yeah, this one also:

  $env:package = 'copyq dbeaver eac'; vagrant up --provision

[ferventcoder]

Here's the path I would suggest going down for now:

Add another folder - use the PowerShell script to run that if there are packages.

Leave the vagrantfile changes alone, only add in the additional script call.

[majkinetor]

Are you sure you want that? It doesn't seem clean too me, multiple different paths doing the installs, not DRY and somewhat confusing. Why would you ever change vagrantfile ? Everything should be achievable via env vars.

[majkinetor]

There is only one benefit in vagrantfile change - its persisted. But, you can equally persist env vars in vagrant file itself on the very top of the file (more visible). I could also add something like /shell/User.ps1 that will let user add its script to be executed at the end, I think way better then what we have now with inline script where you must be careful with escapes and its harder to debug.

[ferventcoder]

Are you sure you want that? It doesn't seem clean too me, multiple different paths doing the installs, not DRY and somewhat confusing. Why would you ever change vagrantfile ? Everything should be achievable via env vars.

You are wanting to support different ways of working with the testing environment. Taking out what you want to achieve now and going to the original stated use of this module, what is wrong with it in its current form?

[majkinetor]

OK, I worked out on some things we talked about.

• I refactored vagrantfile to get DRY
• Added User.ps1 script in repository root (for visibility) that contains code from inline script
• Updated TestPackages script to allow multiple remote + local packages with given versions

Example of use: $Env:PACKAGES='copyq dbeaver:2.7.1'; vagrant up ...

This will take all packages in c:\packages (remote is removed) and remote packages given in env var. and install them. And if you do nothing as before those changes it will behave the same, you just don't edit Vagrantfile but User.ps1 which is IMO much better.

Anyway, I just wanted you to see my changes, perhaps you want to incorporate something or everything or nothing at all.

[majkinetor]

@ferventcoder @gep13

Integrated AU Test-Package with my fork. It can now test install, uninstall or both, along with parameters.

Vagrant environment path is specified via parameter Vagrant or via env. var $au_Vagrant. I currently keep in my profile $Env:au_Vagrant = 'c:\chocolatey\chocolatey-test-environment'. Parameter VagrantClear will remove all packages from packages folder prior to testing.

Example:

C:\work\au-packages\yed> Test-Package  -VagrantClear -Parameters '/Shortcut'

Package info
  Path:         C:\work\au-packages\yed\yed.3.16.2.1.nupkg
  Name:         yed
  Version:      3.16.2.1
  Parameters:   /Shortcut
  Vagrant:      c:\chocolatey\chocolatey-test-environment

Testing package using vagrant
Removing existing vagrant packages
<starts vagrant in another shell>

In another shell

==> default: Running provisioner: shell...
    default: Running: shell/TestPackages.ps1 as c:\tmp\vagrant-shell.ps1
==> default: ============================================================
==> default: TESTING FOLLOWING PACKAGES: yed:3.16.2.1
==> default: ============================================================
==> default:
==> default: ------------------------------------------------------------
==> default: PACKAGE: yed:3.16.2.1
==> default:
==> default: OPTIONS: c:\packages\yed.3.16.2.1.xml
==> default:
==> default: Name                           Value
==> default: ----                           -----
==> default: Install                        True
==> default: Uninstall                      True
==> default: Parameters                     /Shortcut
==> default: ------------------------------------------------------------
==> default:
==> default: TESTING INSTALL FOR yed:3.16.2.1
==> default: Choco cmd: choco install -fy yed --allow-downgrade --version 3.16.2.1 --source "'c:\packages;http://chocolatey.org/api/v2/'"  --params '/Shortcut'
==> default: Chocolatey v0.10.3
==> default: Installing the following packages:
==> default:
==> default: yed
==> default: By installing you accept licenses for the packages.
==> default: yed v3.16.2.1 (forced)
==> default: yed package files install completed. Performing other installation steps.
==> default: File appears to be downloaded already. Verifying with package checksum to determine if it needs to be redownloaded.
==> default: Hashes match.
==> default: Hashes match.
==> default:
==> default: Extracting C:\Users\Administrator\AppData\Local\Temp\chocolatey\yed\3.16.2.1\yEd-3.16.2.1.zip to C:\ProgramData\chocolatey\lib\yed\tools...
==> default: C:\ProgramData\chocolatey\lib\yed\tools
==> default:
==> default: Yed installed in: C:\ProgramData\chocolatey\lib\yed\tools\yed-3.16.2.1
==> default: yed.cmd added to chocolatey bin directory
==> default:  The install of yed was successful.
==> default:
==> default:   Software installed to 'C:\ProgramData\chocolatey\lib\yed\tools'
==> default:
==> default: Chocolatey installed 1/1 packages. 0 packages failed.
==> default:  See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).
==> default:
==> default: Did you know the proceeds of Pro (and some proceeds from other
==> default:  licensed editions) go into bettering the community infrastructure?
==> default:  Your support ensures an active community, it makes you look smarter,
==> default:  plus it nets you some awesome features!
==> default:  https://chocolatey.org/compare
==> default: Exit code for yed:3.16.2.1 was 0
==> default:
==> default: TESTING UNINSTALL FOR yed:3.16.2.1
==> default: Choco cmd: choco uninstall -fy yed
==> default: Chocolatey v0.10.3
==> default: Uninstalling the following packages:
==> default:
==> default: yed
==> default: yed v3.16.2.1 (forced)
==> default:  Skipping auto uninstaller - No registry snapshot.
==> default:  yed has been successfully uninstalled.
==> default: Chocolatey uninstalled 1/1 packages. 0 packages failed.
==> default:  See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).
==> default: Running provisioner: shell...
    default: Running: User.ps1 as c:\tmp\vagrant-shell.ps1
==> default: User script can be added in User.ps1
==> default:
==> default: SUCCESS: Specified value was saved.
==> default: Testing package if a line is uncommented.
==> default: Exit code was 0

[majkinetor]

@ferventcoder

OK, I will close this as I can no longer maintain my master branch and this branch.

All changes are now in my master branch so if/when you want me I can PR it.

AU Test-Package now links to this environment as it doesn't work with original. I did few other changes that significantly speed things up - now package testing provisioners run each time and infrastructure setting runs only once as before; this makes testing much faster and you litterally have to do nothing in test environment except clone it, all other things are done with Test-Package. I might add more machines in the future via parameter.

https://github.com/majkinetor/chocolatey-test-environment