.fixtures.yml: Migrate to git #151
Conversation
bastelfreak
force-pushed
the
fixtures
branch
3 times, most recently
from
a3ec3ab to
f1b71f0
Compare
This is a requirement to update the module dependencies. The dependencies don't support such ancient operating systems.
stdlib 9 namespaced all functions.
This is required for puppetlabs/stdlib 9.
it's best practice to use git branches in unit tests, not the latest forge releases. This approach tries to catch breaking changes or regressions in depenencies before they are released.
|
@ju5t this is the final PR. I tried to split up all changes in individual PRs so we get a proper changelog. |
|
I don't find this approach very developer friendly. If I make a PR to a module, I would like to start with green tests. With this change, it's not unlikely that our tests will fail because a third party module has introduced a breaking change or changed requirements. It could potentially lead to delayed releases too. We/contributors would have to implement fixes for all the breaking changes. Personally, I wouldn't like that. |
|
if you don't like it you can also merge #155, which is the previous PR. I want to point out that the pinned versions in .fixtures.yml are several years old. At the moment the module doesn't work with the versions it mentions in the metadata.json. It provides a false impression. IMO that's worse compared to testing against main/master branches. You need to implement fixes for breaking changes anyway. The question is do you catch them before doing a release or afterwards. Because of that, we (Vox Pupuli) and Puppet switched to testing against branches years ago. That's our recommended best practice. For acceptance tests with beaker/litmus, we test against the actual forge releases. |
|
I agree, testing against old versions makes no sense. Would it be possible to pick the latest released version somehow, instead of the |
|
as far as I know puppetlabs_spec_helper doesn't support that at the moment :( |
|
We'll go the YOLO path for now. Thanks for the insane amount of work! |
it's best practice to use git branches in unit tests, not the latest forge releases. This approach tries to catch breaking changes or regressions in depenencies before they are released.
also contains: