Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows testing using kitchen-vagrant #112

Merged
merged 5 commits into from
Nov 5, 2019

Conversation

dafyddj
Copy link
Contributor

@dafyddj dafyddj commented Aug 22, 2019

I'm putting this out there to gather some opinions.
Would this be useful to add to the formula, despite the fact that the tests can't be run in any CI/CD service that I know of?

Testing requires Virtualbox and Vagrant on the local machine.
The OpenVPN server is first run on a linux box, and the tests are subsequently run on the Windows box.

KITCHEN_YAML=kitchen.windows.yml kitchen converge default-ubuntu
KITCHEN_YAML=kitchen.windows.yml kitchen verify default-windows

Copy link
Member

@myii myii left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just some initial feedback.

.travis.yml Outdated Show resolved Hide resolved
test/salt/pillar/windows.sls Outdated Show resolved Hide resolved
.travis.yml Outdated Show resolved Hide resolved
@myii
Copy link
Member

myii commented Aug 23, 2019

@dafyddj Apologies for the poor-quality communication earlier, both here and in Slack -- I was out and about so it got a bit messy. I'm glad you figured out what I was trying to say!

I'm putting this out there to gather some opinions.
Would this be useful to add to the formula, despite the fact that the tests can't be run in any CI/CD service that I know of?

I'd very much welcome Windows testing, even if it was only local. It would help with PRs that have got stuck, such as the following:

In terms of CI/CD, there's a potential solution. You may have noticed that Cirrus CI has been enabled for this org's repos and is being used for a few of them (e.g. rkhunter and syslog-ng). They also have Windows Containers available, which could be useful. We've had contact with Cirrus CI and they were responsive and helpful, both on GitHub and via. e-mail, such as the discussion going forward from here:

@dafyddj
Copy link
Contributor Author

dafyddj commented Aug 23, 2019

I have had a little play with kitchen-docker using Windows containers (support was only added a matter of weeks ago), and there's a slight gotcha in that files cannot be uploaded to the container while it's running - so, at least at the moment, it's not really a viable testing method.

@dafyddj
Copy link
Contributor Author

dafyddj commented Oct 22, 2019

@myii care to take another look at this?

I've changed the approach a little: pre-Salted Windows image; re-use of Inspec tests and kitchen.yml.
Comments welcome.

@myii
Copy link
Member

myii commented Oct 22, 2019

@dafyddj Sounds good! I'll try to have a look at this soon.

Copy link
Member

@myii myii left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dafyddj This is an excellent PR! I can see this becoming the basis for all sorts of Vagrant-based testing across our formulas. Thank you very much for addressing this problem.

I've got a few requests that I've mentioned inline. I haven't clearly defined the one about a separate test pillar, so please shout if anything's unclear. I also want to draw the attention of the other contributors to this, so we can confirm a standard structure that can be used in other formulas as well.


Checked with: myii/ssf-formula#81

.yamllint Outdated Show resolved Hide resolved
.yamllint Show resolved Hide resolved
Gemfile Outdated Show resolved Hide resolved
kitchen.yml Outdated Show resolved Hide resolved
kitchen.yml Outdated Show resolved Hide resolved
@myii
Copy link
Member

myii commented Oct 23, 2019

@dafyddj Whatever decision is reached, it would be good to update the testing section in the README to explain how to run the local Vagrant-based testing.

@dafyddj
Copy link
Contributor Author

dafyddj commented Oct 23, 2019

While I look over this, what do you think of this approach (1037162) whereby .sls files are rendered to .yaml before being linted by yamllint? (kitchen.yml could be rendered in a similar way.)

@dafyddj
Copy link
Contributor Author

dafyddj commented Oct 23, 2019

Resulting Travis output here.

@dafyddj
Copy link
Contributor Author

dafyddj commented Oct 23, 2019

@dafyddj Whatever decision is reached, it would be good to update the testing section in the README to explain how to run the local Vagrant-based testing.

Yes, this is on my TODO list.

@myii
Copy link
Member

myii commented Oct 23, 2019

While I look over this, what do you think of this approach (1037162) whereby .sls files are rendered to .yaml before being linted by yamllint? (kitchen.yml could be rendered in a similar way.)

@dafyddj This has crossed my mind plenty of times, since getting my hands dirty with all of the linters. It's nice to see a working method. It definitely appeals to the perfectionist in me but that's not necessarily a good thing! Having cast my eye over a lot of debug output, it's obvious that we'd have to use a fairly relaxed set of yamllint rules, which would be easy to do via. a secondary configuration file (that can be customised per formula).

So what are my concerns? They're a bit elusive right now but I suppose one is that we could end up distracting ourselves unnecessarily, or giving ourselves too many hoops to jump through. Another is that the lint won't cover the whole of each source file; the rendered files will miss sections due to conditionals, etc. The issue surrounding jinja_env:trim_blocks also springs to mind -- in that, we could end up with excellent rendered output, which actually breaks when used by consumers.

I'd still like to see this in action, though. How about we do this in a separate job with jobs:allow_failures set, like we had with rubocop? That will give us a chance to see how it works out. We can also share our findings with the others, to attempt to achieve a consensus.

Please don't mistake this as a negative response in any way. I would definitely use this in a personal capacity, within a well-defined environment. My feedback here is more measured, trying to consider the wider implications.

@myii
Copy link
Member

myii commented Oct 23, 2019

@dafyddj Another reason for having a general purpose kitchen.vagrant.yml: supporting FreeBSD images as well. There's a fairly long thread on Slack but today's update is here:

- - -
16:06 myii @​kp We're getting closer to establishing Vagrant-based testing again: https://saltstack-formulas/openvpn-formula #112. We could easily add the FreeBSD images to the kitchen.vagrant.yml file. How are you getting along with the pre-salted images? CC: @​noel.mcloughlin.
16:10 kp @​myii thanks for the pointer, was pretty busy with $real_job issues, I hope I can prepare something meaningful this weekend
16:10 myii Excellent, look forward to it.

@dafyddj dafyddj force-pushed the kitchen-vagrant branch 2 times, most recently from bc7b160 to d2575e2 Compare October 23, 2019 18:53
@myii
Copy link
Member

myii commented Oct 25, 2019

@dafyddj Is this still a WIP?

@dafyddj
Copy link
Contributor Author

dafyddj commented Oct 25, 2019

Yes, still have a couple of things to add to it.

@myii
Copy link
Member

myii commented Oct 25, 2019

@dafyddj OK, please ping me when you're ready for the next stage.

@dafyddj dafyddj changed the title WIP: Windows testing using kitchen-vagrant Windows testing using kitchen-vagrant Oct 28, 2019
@dafyddj
Copy link
Contributor Author

dafyddj commented Oct 28, 2019

@myii I've added to the documentation and updated my Vagrant box (to version 2019.10.141), so this PR is ready for further review.

docs/README.rst Show resolved Hide resolved
  * so that adapters are created before service is started
  * use `rspec-retry` to make retrying the logfile test
    platform-independent
  * do some DRYing of the inspec control files
@myii myii merged commit 5a263e0 into saltstack-formulas:master Nov 5, 2019
@saltstack-formulas-travis

🎉 This PR is included in version 0.15.4 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants