You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -45,47 +45,77 @@ You will have someone by your side in this process. The general flow is to…
45
45
* At that point you can transfer your own repository.
46
46
* If migrating a module from puppetlabs, re-enable github issues.
47
47
* Verify that all webhooks except travis are disabled.
48
-
* Update the README.md with a description of the deprecation and a link to the new module location.
48
+
* Update the README.md with a description of the deprecation and a link to the
49
+
new module location.
49
50
* Release a copy of your module to the 'puppet' forge account.
50
-
* Add the module to our [modulesync setup](https://github.com/voxpupuli/modulesync_config/blob/master/managed_modules.yml).
51
-
* Add the module to our [plumbing repository](https://github.com/voxpupuli/plumbing/blob/master/share/modules)(handles travis secrets).
52
-
* Ask an admin to add the `collaborators` team to the module's `Collaborators & Teams` 'Teams' list with `Write` permissions (e.g. https://github.com/voxpupuli/puppet-gitlab/settings/collaboration).
* Create a Jira issue at https://tickets.puppetlabs.com and ask to deprecate the old module (and approve the new one if the old one was approved as well).
55
-
56
-
If you have many modules you wish to migrate, this will be cumbersome.
57
-
In this case we will generally create a separate group and give you
58
-
administrator access to speed things up.
59
-
60
-
If you are interested in Vox Pupuli accepting a module *that you do not own*, the process has a few extra steps before beginning the checklist above.
61
-
We do ask that you show that reasonable efforts have been made to engage the owner and they are unresponsive.
62
-
If the owner has responded and is not interested in migrating their module to VP, it will be evaluated on a case by case basis.
63
-
To start the process, document your request and efforts in a brief email to the [mailing list](https://groups.io/g/voxpupuli/).
64
-
If the module is accepted, VP will work with you to determine the proper fork/migration steps needed in addition to the checklist above.
60
+
* Create a Jira issue at https://tickets.puppetlabs.com and ask to deprecate the
61
+
old module (and approve the new one if the old one was approved as well).
62
+
63
+
If you have many modules you wish to migrate, this will be cumbersome. In this
64
+
case we will generally create a separate group and give you administrator access
65
+
to speed things up.
66
+
67
+
If you are interested in Vox Pupuli accepting a module *that you do not own*,
68
+
the process has a few extra steps before beginning the checklist above. We do
69
+
ask that you show that reasonable efforts have been made to engage the owner and
70
+
they are unresponsive. If the owner has responded and is not interested in
71
+
migrating their module to VP, it will be evaluated on a case by case basis. To
72
+
start the process, document your request and efforts in a brief email to the
73
+
[mailing list](https://groups.io/g/voxpupuli/). If the module is accepted, VP
74
+
will work with you to determine the proper fork/migration steps needed in
75
+
addition to the checklist above.
65
76
66
77
## Publishing a module - setup
67
78
Forge publishing is handled by travis and puppet-blacksmith.
68
79
69
-
To guarantee a frictionless process across all modules, we use [modulesync](https://github.com/voxpupuli/modulesync). Our modulesync configuration is available at [modulesync_config](https://github.com/voxpupuli/modulesync_config).
80
+
To guarantee a frictionless process across all modules, we use
Most modulesync'ed settings can be overridden through a [.sync.yml](https://github.com/voxpupuli/puppet-extlib/blob/master/.sync.yml). You may also need to (re)define your travis testing matrix with respect to puppet version. This prevents the deploy hook from running once for each version of puppet defined in your testing.
85
+
Most modulesync'ed settings can be overridden through a
You may also need to (re)define your travis testing matrix with respect to
88
+
puppet version. This prevents the deploy hook from running once for each version
89
+
of puppet defined in your testing.
72
90
73
-
Travis needs to be aware of the rename, this can be done by pushing a single commit. Travis needs to be enabled for the new repository, you can do that [here](https://travis-ci.org/profile/voxpupuli).
91
+
Travis needs to be aware of the rename, this can be done by pushing a single
92
+
commit. Travis needs to be enabled for the new repository, you can do that
93
+
[here](https://travis-ci.org/profile/voxpupuli).
74
94
75
-
The secure line is unique per repository and often the only line in .sync.yml. To get a secure line:
95
+
The secure line is unique per repository and often the only line in .sync.yml.
96
+
To get a secure line:
76
97
77
-
Ask an admin (or submit a PR) to add your module to the list [here](https://github.com/voxpupuli/plumbing/blob/master/share/modules). Then an admin will run the encrypt_travis.sh script and push a new version of [this](https://github.com/voxpupuli/plumbing/blob/master/share/travis_secrets) which you can then copy and paste your travis secure line from.
98
+
Ask an admin (or submit a PR) to add your module to the list
99
+
[here](https://github.com/voxpupuli/plumbing/blob/master/share/modules). Then an
100
+
admin will run the encrypt_travis.sh script and push a new version of
which you can then copy and paste your travis secure line from.
78
103
79
-
Note that you need to mask your ``secure:`` line in .travis.yml from modulesync. [Here](https://github.com/voxpupuli/puppet-iis/blob/master/.sync.yml#L35) is an example of what that looks like.
104
+
Note that you need to mask your ``secure:`` line in .travis.yml from modulesync.
105
+
[Here](https://github.com/voxpupuli/puppet-iis/blob/master/.sync.yml#L35) is an
106
+
example of what that looks like.
80
107
81
-
If the forge puppet password is changed, an admin can run encrypt_travis.sh and the modules can bring in the new password on their own schedule.
108
+
If the forge puppet password is changed, an admin can run encrypt_travis.sh and
109
+
the modules can bring in the new password on their own schedule.
82
110
83
111
84
-
Gem publishing is handled similarly, except there is not a unified user. Each gem owner is responsible for their own .travis.yml
112
+
Gem publishing is handled similarly, except there is not a unified user. Each
113
+
gem owner is responsible for their own .travis.yml
85
114
86
115
## Releasing a new version of a module
87
116
88
-
*Please note that in order to perform a release you must be in the __Collaborators__ group on Github for the module in question.*
117
+
*Please note that in order to perform a release you must be in the
118
+
__Collaborators__ group on Github for the module in question.*
89
119
90
120
Run modulesync to ensure the dotfiles are up to date.
91
121
@@ -138,45 +168,95 @@ Travis will then kick off a build against the new tag created and deploy that bu
138
168
139
169
There are a few things that can be checked if you review a pull request against one of our modules:
140
170
141
-
* Does the email address used in the commits match the github email address? (This will let github display the contributor's avatar next to the commit)
142
-
* Is this a bugfix, modulesync, breaking change, enhancement, docs update? Label it with `bug`, `modulesync`, `backwards-incompatible`, `enhancement`, `docs`
171
+
* Does the email address used in the commits match the github email address?
172
+
(This will let github display the contributor's avatar next to the commit)
173
+
* Is this a bugfix, modulesync, breaking change, enhancement, docs update? Label
174
+
it with `bug`, `modulesync`, `backwards-incompatible`, `enhancement`, `docs`
143
175
* Are updates to the README.md needed but missing? Label it with `needs-docs`
144
176
* Has the file documented params or examples in the header? This needs to be updated as well
145
177
* Are there merge conflicts? Add the `needs-rebase` label
146
178
* Does it need additional tests? Add the `needs-tests` label
147
179
* Does it have failing tests? Add the `tests-fail` label
148
180
* Are new parameters introduced? They must have datatypes
149
-
* Are facts used? They should only be accessed via `$facts[]` or [fact()](https://github.com/puppetlabs/puppetlabs-stdlib#fact) from stdlib, but not topscope variables
150
-
* In the majority of cases, variables shouldn't be accessed via topscope: $::modulename::$param. Instead do: $modulename::$param
151
-
* Are datatypes from stdlib used? Ensure that lowest supported stdlib version is 4.13.1. Check if a newer version introduced the used datatype
152
-
* Are hiera yaml files added for data-in-modules? Ensure that the lowest supported Puppet version is 4.10.0 and that the data is compatible with [hiera 5](https://puppet.com/docs/puppet/5.3/hiera_migrate.html#use-cases-for-upgrading-to-hiera-5)
153
-
* Are there new params with datatype Hash or Array? If possible, they should default to empty Hash/Array instead of undef. You can also enforce the datastructure like Array[String[1]]
154
-
* Are there new params with datatype Boolean? The default value is a tricky decision which needs careful reviewing. Sometimes a True/False is the better approach, sometimes undef
155
-
* Is this a bugfix? Write the Pull Request Title in a way that users can easily identify if they are impacted or not
156
-
* Does a new param map to an option in a config file of a service? The Parameter should accept the possible values that the service allows. For example 'on' and 'off'. Don't accept a boolean that will be converted to 'on' or 'off'
157
-
* Is a new template added? The preferred language is [epp](https://puppet.com/docs/puppet/latest/lang_template_epp.html), not [erb](https://puppet.com/docs/puppet/latest/lang_template_erb.html)
158
-
* Is a new class added? It should have unit tests using [rpsec-puppet-facts](https://github.com/mcanevet/rspec-puppet-facts#rspec-puppet-facts) that at least verify that the new class compiles
159
-
* Files should always terminate with a newline if possible, with an exception being file or template fragments like those used with concat. This is the [POSIX standard](http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206), and some tools don't handle the lack of a terminating newline properly
160
-
* If you can supply one or multiple values for an attribute it's common practice to enforce the datatype for one value and an array of that datatype. An example for string is `Variant[String[1],Array[String[1]]]`. This can be used in the Puppet code as `[$var].flatten()`
181
+
* Are facts used? They should only be accessed via `$facts[]` or
182
+
[fact()](https://github.com/puppetlabs/puppetlabs-stdlib#fact) from stdlib,
183
+
but not topscope variables
184
+
* In the majority of cases, variables shouldn't be accessed via topscope:
and some tools don't handle the lack of a terminating newline properly
213
+
* If you can supply one or multiple values for an attribute it's common practice
214
+
to enforce the datatype for one value and an array of that datatype. An
215
+
example for string is `Variant[String[1],Array[String[1]]]`. This can be used
216
+
in the Puppet code as `[$var].flatten()`
161
217
* The parameter section should always be aligned at the `=` char
162
-
* Is a class considered private? Then it should contain [assert_private](https://github.com/puppetlabs/puppetlabs-stdlib#assert_private)
163
-
* A module should have as few public interfaces as possible. It should be aimed for the init.pp being the only public class. This is not a rule but a general guideline. Depending on the module, it is not always possible or feasible to configure everything through a single class.
164
-
* Is another module added as a dependency? Add it to the `.fixtures.yml` file as a git repository (as a `https://` link, not `ssh` or `git://`). Spec tests always run against master branches to detect breaking changes as early as possible. Acceptance tests use the last release (installed by [install_module_dependencies](https://github.com/puppetlabs/beaker-module_install_helper#install_module_dependencies) which parses it from the `metadata.json`)
165
-
* Only hard dependencies must be added to the metadata.json. Don't add soft dependencies! More explanation is [in the official Puppet styleguide](https://puppet.com/docs/puppet/5.5/style_guide.html#dependencies)
166
-
* Ensure that the version range of any dependency doesn't include an unreleased major version (do not allow version 6.X of a dependency if the current version is 5.X)
167
-
* An increase of an upper version boundary (of a module or Puppet itself) is only an enhancement if code adjustments were needed. Don't add the `enhancement` label if the only change is within the `metadata.json`. Ensure that `.fixtures.yml` doesn't pin a specific version.
218
+
* Is a class considered private? Then it should contain
* Ensure that the version range of any dependency doesn't include an unreleased
234
+
major version (do not allow version 6.X of a dependency if the current version
235
+
is 5.X)
236
+
* An increase of an upper version boundary (of a module or Puppet itself) is
237
+
only an enhancement if code adjustments were needed. Don't add the
238
+
`enhancement` label if the only change is within the `metadata.json`. Ensure
239
+
that `.fixtures.yml` doesn't pin a specific version.
168
240
169
241
170
242
### Approving and Merging
171
243
172
-
* You can merge your own PR if it was approved by someone else and travis is green. Don't merge if either one of those conditions are not true
173
-
* Modulesync PRs are an exception (a PR based on changes that the msync tool did, NOT PRs on [modulesync_config](https://github.com/voxpupuli/modulesync_config#modulesync-configs)). We agreed some time ago that it's ok to merge your own modulesync PR if travis is green, without separate approval. This is okay because changes to [modulesync_config](https://github.com/voxpupuli/modulesync_config#modulesync-configs) were reviewed and tested
174
-
* It's okay to approve code regardless if travis is still running or not. The code won't be merged if travis fails after the PR got approved
244
+
* You can merge your own PR if it was approved by someone else and travis is
245
+
green. Don't merge if either one of those conditions are not true
246
+
* Modulesync PRs are an exception (a PR based on changes that the msync tool
0 commit comments