-
Notifications
You must be signed in to change notification settings - Fork 352
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
(CODEMGMT-1415) Sundry Improvements #1211
(CODEMGMT-1415) Sundry Improvements #1211
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the first commit could use a short description of the bug.
Are you planning to add the acceptance test as part of this PR, or should we merge this first to unblock code-manager's unit tests?
I was planning on doing the acceptance test as part of this work. We should see how long it takes me to run the damned things, if I don't have it by tomorrow we can merge, I guess. |
I'm fine waiting for now, I don't think we're landing anything more in code-manager right away. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 to updating the commit message to describe the bug
In commit 9d0579f Environments stopped interrogating their Puppetfile for managed content needed to calculate their purge exclusions, but moved to using the data returned by the ModuleLoader when loading content. However, if content was not loaded prior to attempting to purge the environment then the environment would purge much of the Puppetfile managed content. This would happen when running `r10k deploy environment` (without `--modules`) on an existing environment. To resolve this we now conditionally load module data if it hasn't been loaded yet when resolving our purge exclusions.
Concerns were raised that `--assume-unchanged` required knowing too much about how R10K internals work and that users would be well aware of this kind of behavior from back up tools where the `--incremental` is the standard terminology.
When evaluating how to test `--incremental` behavior it was decided that the existing acceptance tests lacked basic sanity tests (there was an uncaught bug when running a simple `r10k deploy environment` twice). This provides basic acceptance level testing for running `r10k deploy environment` with and without `--modules` and `--incremental`.
Co-authored-by: Molly Waggett <[email protected]>
1fc43c3
to
4acfacb
Compare
When implementing and refactoring the Puppetfile ModuleLoader logging that happened on instantiation of the Puppetfile was moved to the instantiation of the ModuleLoader. However, the a ModuleLoader is instantiated for both the legacy Puppetfile as well as the owning Environment directly, causing the log lines to be emitted twice.
I'm having a lot of trouble running the acceptance tests locally. I think it's at a place where it can be reviewed at least while I continue to try and run the test. I also believe I've address the comments so far and added a new commit cleaning up some logging. |
Cool, I'll take a look, and also try to run your test. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this looks good so long as the test passes. It checks all the boxes I would want to see for the basic workflow.
end | ||
|
||
step 'Test --modules --incremental updates changed modules' do | ||
on(master, "#{r10k_fqp} deploy environment production --modules --incremental --verbose=debug1") do |result| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Without a new Puppetfile, this deploy isn't actually changing anything, is it? Is there a better way we can test this behavior other than checking the log messages? Just trying to think in terms of actual workflows, since I don't imagine someone would run a deploy with --modules
and then again with --modules --incremental
without at least making some sort of change in between?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I struggled with this. The end result of running --modules
vs --modules --incremental
should be the same, modules that should be updated will be updated. However, the how it happens is different, with some modules being skipped completely and some still being checked. So the logging shows us at least that the static version checking is correct (for a forge module) and that unchanged static modules are skipped.
If you think I should I could include all the permutations of different types of versions as well as those that have changed definitions? Or are you mainly concerned about those modules whose definition changed on disk part? I could include one of those in the Puppetfile.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll add a module that is updated in this invocation to test the changeable vs static, changed vs static, unchanged. Let me know if you'd like more permutations of static version checking (fwiw, there is some unit tests around that: 6f46384#diff-1bc365ddca4e6e4a7ba95ff4d655c036faa16ec1025e35bc559476265a5719aaR344-R389)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think what you added looks good! I'm satisfied with the various permutations we test here.
99535d1
to
5042804
Compare
I've tested this test, with current HEAD of pe-r10k (80392485):
As well as this content (e5b714d29):
|
Running the whole suite now |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feel free to merge once you're satisfied with your suite run. |
--modules
--assume-unchanged
flag to--incremental
Still to do