ActiveDirectoryDsc: Proof of Concept - Running local integration tests
Pull Request (PR) description
The goal I had was to be able to run the integration tests on a VM in Hyper-V using Pester and get the Pester output in the console on the host. I had this laying around for a long time now, and spent the weekend converting it to handle the new pipeline which helped with a few steps, and then I wanted to finish this to a point where it is was working. This is a PoC of that which now runs three of the integration tests in a Hyper-V VM. Comments appreciated! :smile:
There are many manual steps to get to a point where we can run tests. I like to see if we can use any automation tool to help with this, all of this or parts of this. Tools like AutomatedLab, LabBuilder, Lability, or Test Kitchen might help. The reason I focused on using Hyper-V is the seemless integration with PowerShell Direct.
I like to extend this PoC to all the integrations tests we have and also setting up child domain. I looking to have 4 nodes in the lab depending on the memory usage needed by the host.
README.md: https://github.com/dsccommunity/ActiveDirectoryDsc/blob/2d86b1767f3b8240744e9c73904e04be51a7a514/Tests/README.md
Todo:
- Lower the memory for each VM but still being able to run the integration tests (currently 4GB per VM)
- Fix the rest of the available integration tests so they run.
- Setup 2 DC's in parent and 2 DC's in child (and potentially read-only DC's and different sites) - memory usage will limit us here.
- Run integration tests using certificate
This Pull Request (PR) fixes the following issues
- Fixes #121
Task list
- [x] Added an entry to the change log under the Unreleased section of the file CHANGELOG.md. Entry should say what was changed and how that affects users (if applicable), and reference the issue being resolved (if applicable).
- [ ] Resource documentation added/updated in README.md.
- [ ] Resource parameter descriptions added/updated in README.md, schema.mof and comment-based help.
- [ ] Comment-based help added/updated.
- [ ] Localization strings added/updated in all localization files as appropriate.
- [ ] Examples appropriately added/updated.
- [ ] Unit tests added/updated. See DSC Community Testing Guidelines.
- [x] Integration tests added/updated (where possible). See DSC Community Testing Guidelines.
- [x] New/changed code adheres to DSC Community Style Guidelines.
Hi @johlju, just a few grammar/typo fixes in reviewable.
Unfortunately, I don't have a Hyper-V host to test it with (my home lab is ESXi).
The way I have been running the integration tests is by git cloning the whole repo onto my test domain controller, then running build.ps1 build then invoke-pester on the relevant integration test. I see you are proposing to remove the code that runs Initialize-TestEnvironment from each integration test, what affect will that have on this process?
I see you are proposing to remove the code that runs Initialize-TestEnvironment from each integration test, what affect will that have on this process?
Yes it will, but maybe we shouldn't break your scenario π€ I will figure out a way so both ways works.
I tried to use the build process to initiate the tests but that is not 100% when the node reboots since the Initialize-TestEnvironment sets the machine PSModulePath and then Restore-TestEnvironment removes it at the end of the tests, meaning that after a reboot the configuration cannot be run automatically because the modules cannot be found. But for integration tests that will not reboot it works though. Maybe we can solve this by not running Restore-TestEnvironment if a resource requested a reboot? π€
try
{
# ...
$DscConfigurationStatus = Get-DscConfigurationStatus
if ($DscConfigurationStatus.RebootRequested)
{
return
}
# ...
}
finally
{
if ($DscConfigurationStatus.RebootRequested)
{
Write-Warning 'A Reboot has been requested by the DSC. Please reboot then re-run the test'
}
else
{
Restore-TestEnvironment -TestEnvironment $script:testEnvironment
}
}
I added a section for VMware as you described it. I have VMware ESXi as well but it is not as easy as running remote scripts like Hyper-V is, but did see that PowerCLI has the Invoke-VMScript that could be used to not need to RDP into a VM I have to dig around this, but let's focus get one scenario working first. I figure most contributors have a Windows 10 with Hyper-V available, though they might not have memory needed to run VMs. :/ @X-Guardian are you running everything in a remote PowerShell Session (like Enter-PSSession) or do you RDP into the VM?
In this Hyper-V scenario I want to look into:
- AutomatedLab that can help lower the steps need in the two first sections. After reading the blog article by @jpomfret it looks like there are just a few steps getting clean servers up; https://jesspomfret.com/automatedlab-sql-server/
- Using the build pipeline as discussed above (it will help setting up certificate too).
- (plus something else I forgot while writing this π)
I RDP onto the VM, and it is a very manual process. Agreed you should initially focus on Hyper-V and getting to an automated process.
I will get back to this PR eventually. But need to give SqlServerDsc much needed love first.
Labeling this pull request (PR) as abandoned since it has gone 14 days or more since the last update. An abandoned PR can be continued by another contributor. The abandoned label will be removed if work on this PR is taken up again.
Labeling this pull request (PR) as abandoned since it has gone 14 days or more since the last update. An abandoned PR can be continued by another contributor. The abandoned label will be removed if work on this PR is taken up again.
Codecov Report
Merging #592 (84c9de0) into main (b2838d9) will not change coverage. The diff coverage is
n/a.
@@ Coverage Diff @@
## main #592 +/- ##
===================================
Coverage 98% 98%
===================================
Files 25 25
Lines 3471 3471
===================================
Hits 3402 3402
Misses 69 69
Labeling this pull request (PR) as abandoned since it has gone 14 days or more since the last update. An abandoned PR can be continued by another contributor. The abandoned label will be removed if work on this PR is taken up again.
Labeling this pull request (PR) as abandoned since it has gone 14 days or more since the last update. An abandoned PR can be continued by another contributor. The abandoned label will be removed if work on this PR is taken up again.