I’ve been using Ansible fruitfully to provision a windows 2012 server in AWS, so I can use that as the basis for baking an AMI and moving my environment closer towards immutable infrastructure.
In the doing, I’ve been using the chocolatey package manager.
Note that chocolatey will be replaced by oneget once powershell v5 comes out. The only expected difference is that instead of choco install thing one runs powershell install-package thing - mostly.
I’ve not created a module before - any steers that people can give me in terms of how to automate testing for it (given the windows context, I imagine that might be trickier) would be welcome.
The chocolatey commands are a bit tricky because the outout text and not objects, so I’ve made an attempt at some rudimentary text parsing to get results.
Having forked from ansible/ansible - your fork doesn’t appear in my list of possibilities when creating a PR. Any idea how I can solve that? Or, can you add me as a collaborator to yours and I can push directly to a branch of win_chocolatey there?
Hm, it might be better for you to actually own it if you plan on doing some work on it. I was just goofing around a bit and got kinda thrown off track when I realized that there would be so much string parsing involved. I don’t mind if you just take the module and maintain/PR it from your fork.
Or if you’d rather, I can give you push access to my fork, up to you.
Am I right to think that I can try this out as a local module in a playbook I’m writing by creating a library directory in my playbook’s root directory, then a directory called win_chocolatey in that, and place the two win_chocolatey files in there…?
Good question. I was meaning to ask Michael if we could have a “debug” option to ease the testing on PowerShell modules.
I usually just copy the module I’m testing to ansible/library/windows and create some arbitrary test playbook when I’m goofing around. There might be better ways. And you only need the .ps1 file, the other one is just for documentation.
Let me know if you need anything more detailed, and I’d be happy to help you get setup.
That sounds ok too; I’ll try both and see which works for me. It’d be great to know how to iterate on windows modules effectively; perhaps I’ll drop a README.md into that directory with some guidance as I go.
I try to write integration tests as my example playbooks while I'm creating
or updating a module. My usual steps go something like:
- Copy test/integration/inventory.winrm.example to inventory.winrm and add
my test hosts
- Create a test role with tasks in
test/integration/roles/test_win_foo/tasks/default.yml
- Edit test/integration/test_winrm.yml to add my test_win_foo role
- Create/update module code in library/windows/win_foo.ps1, docs in
library/windows/win_foo
- Run tests for my role: cd test/integration; TEST_FLAGS="-vvvv -t
test_win_foo" make test_winrm
- Add --limit host to TEST_FLAGS to target only a single host
- Temporarily add tags to selected tasks and use -t my_tag while I'm
debugging/testing specific tasks
- Use --start-at-task='task name' to skip tasks I don't need to run each
time
- Repeat until the cows come home
There's no requirement to include any tests when you submit a module, but
it can help in getting a pull request reviewed and merged sooner.
As regards running tests when I add those - I’m going to assume that you guys have Windows boxes to run tests on in a cloud or similar? I’ve been iterating on this via the latest Windows 2012 R2 AWS AMI (2014.08.13, ami-6abd621d in eu-west-1) as part of some at-work work.
In terms of developing and iterating it, I have my playbook and I was able to successfully write the module inline to my playbook (exactly as the docs indicate, yay!) by creating a structure like this
It would be really handy, by the way, if ansible-playbook had a mode where it would ship the scripts and modules to the windows node, execute them, but then not immediately delete them after execution, so that one can manually look at what arrived. Does that exist?