Open alxwr opened 2 years ago
@daks @myii @javierbertoli
(Sorry for pulling you into my struggle. :-) But from your recent activity I derived that you are among the most active within saltstack-formulas.)
I have a quick question regarding CI: is there any documentation on how this is supposed to work? I don't have any idea where to start without jeopardizing previous work. (I fully agree that CI is a valuable tool, but am I supposed to fix CI before I can merge a PR?)
@alxwr no problem :) FYI I'm not using salt anymore since several months and don't have a lot of time to invest in formulas management.
About CI: I don't think there is any documentation, and it should, because setup has changed several times (software used, provider...) and only a few maintainers can keep informed about those. The general formulas management (github accounts, ssf-formula...) feels under-documented for me amd complicates new contributors integration.
About fixing CI: I tend to think it should be fixed but it's not always possible. The ideal situation would be that CI is not broken and the minimal requirement for a PR is: do not break it! :)
PR progress checklist (to be filled in by reviewers)
What type of PR is this?
Primary type
[build]
Changes related to the build system[chore]
Changes to the build process or auxiliary tools and libraries such as documentation generation[ci]
Changes to the continuous integration configuration[feat]
A new feature[fix]
A bug fix[perf]
A code change that improves performance[refactor]
A code change that neither fixes a bug nor adds a feature[revert]
A change used to revert a previous commit[style]
Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)Secondary type
[docs]
Documentation changes[test]
Adding missing or correcting existing testsDoes this PR introduce a
BREAKING CHANGE
?No.
Related issues and/or pull requests
https://github.com/saltstack-formulas/mysql-formula/pull/187
Describe the changes you're proposing
Set
tpldir
in the context of the template.Pillar / config required to test the proposed changes
None.
Debug log showing how the proposed changes work
Documentation checklist
README
(e.g.Available states
).pillar.example
.Testing checklist
state_top
).Additional context
I didn't write tests, because this SLS configures the network manager, not OpenVPN itself. (I was reluctant to add another dependency to the existing test suite.)