This page is far from finished but contains some basic information on getting started. If you have any questions reach out to us in #voxpupuli on Freenode.
Anyone can participate in voxpupuli. We currently have four levels of participation, orchestrated by github teams.
We have a number of communication channels:
IRC still counts as the preferred point of contact for many of us but we tend to be available and reachable through both. If you need to reach out to a maintainer because of behaviour in our community that you find questionable please read through our Code of Conduct, you’ll find a contact address there.
Longer form cross-project discussion tends to take place on the mailing list, as well as release announcements.
You will have someone by your side in this process. The general flow is to…
collaboratorsteam to the module’s
Collaborators & Teams‘Teams’ list with
Writepermissions (e.g. https://github.com/voxpupuli/puppet-gitlab/settings/collaboration).
If you have many modules you wish to migrate, this will be cumbersome. In this case we will generally create a separate group and give you administrator access to speed things up.
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. We do ask that you show that reasonable efforts have been made to engage the owner and they are unresponsive. 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. To start the process, document your request and efforts in a brief email to the mailing list. If the module is accepted, VP will work with you to determine the proper fork/migration steps needed in addition to the checklist above.
Forge publishing is handled by travis and puppet-blacksmith.
Most modulesync’ed settings can be overridden through a .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.
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.
The secure line is unique per repository and often the only line in .sync.yml. To get a secure line:
Ask an admin (or submit a PR) to add your module to the list here. Then an admin will run the encrypt_travis.sh script and push a new version of this which you can then copy and paste your travis secure line from.
Note that you need to mask your
secure: line in .travis.yml from modulesync. Here is an example of what that looks like.
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.
Gem publishing is handled similarly, except there is not a unified user. Each gem owner is responsible for their own .travis.yml
Please note that in order to perform a release you must be in the Collaborators group on Github for the module in question.
Run modulesync to ensure the dotfiles are up to date.
Create a ‘release pr’. This pull request updates the changelog and bumps the
version number to the target version, removing all release candidate
identifiers, i.e. from
0.10.7. Here’s an example:
puppet-extlib’s 0.10.7 release.
In most cases it is sufficient to update metadata.json. We try
to honor semantic versioning and decided that dropping ruby1.8
support is a major change and requires a major version bump for the module.
(Only the minor version should be bumped if the module is pre version 1.0 and
ruby 1.8 support has been dropped.)
If necessary, run
bundle install before continuing. If you want you can also only install the needed gems:
bundle install --path .vendor/ --without system_tests development
And in case you installed the gems before:
bundle install --path .vendor/ --without system_tests development; bundle update; bundle clean
We can generate the changelog after updating the metadata.json with a rake task:
bundle exec rake changelog
Get community feedback on the release pr, label it with skip-changelog, get it merged.
Checkout an updated copy of master (
git checkout master; git fetch origin; git pull origin master)
Run the rake target
travis_release. This will:
-rc0to the end
bundle exec rake travis_release
Travis will then kick off a build against the new tag created and deploy that build to the forge. Caution: The Vox Pupuli repo has to be the configured default branch in your local clone. Otherwise you will try to release to your fork.
There are a few things that can be checked if you review a pull request against one of our modules:
$factsor fact() from stdlib, but not topscope variables
Variant[String,Array[String]]. This can be used in the Puppet code as
.fixtures.ymlfile as a git repository (as a
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 which parses it from the
enhancementlabel if the only change is within the
metadata.json. Ensure that
.fixtures.ymldoesn’t pin a specific version.