Module sync configurations for Vox Pupuli Modules
git clone https://github.com/voxpupuli/modulesync_config.git
cd modulesync_config
git checkout $(git tag --list | sort -V | tail -n1) # checkout latest tag
bundle install
bundle exec msync help updatebundle exec msync update -f {module_name} --message "modulesync $(git describe)"bundle exec msync update -f {module_name} --noop
cd modules/{module_name}
# edit then git commit/pushThis will sync everything in the managed_modules.yml.
bundle exec msync update --message "modulesync $(git describe)"Now you can use hub to create pull requests.
./bin/create-pull-requestsYou can now also create pull requests with modulesync directly:
export GITHUB_TOKEN=token
bundle exec msync update --message "modulesync $(git describe)" --pr --pr-labels modulesync --pr-title "modulesync $(git describe)"./bin/clean-git-checkoutsWe have a nice script to detect a bunch of maintenance jobs in our modules. For example wrong puppet version constraints or missing support for new operating systems:
bundle install --path --without development
export GITHUB_TOKEN=token
bundle exec bin/get_all_the_diffsYou can also pass DEBUG=true as an environment variable to the script. to get
a bit more output.
Ideally speaking all modules are compatible with the latest forge releases. To do this manually is tedious so tools have been written.
First off all, make sure all modules are checked out and up to date. For example:
bundle exec msync update --noop -b update-dependenciesIf you already have all checkouts, ./bin/clean-git-checkouts can also be
used.
Now it's time to get a list
bundle exec rake metadata_depsIf you see puppetlabs/stdlib has made a new major release (we'll use 7.x in
this example), you need to set the upper bound to 8.0.0:
./bin/bump-dependency-upper-bound puppetlabs/stdlib 8.0.0 modules/*/*/metadata.jsonYou can verify it worked by running rake metadata_deps again.
Of course this means nothing until you actually submit the change. To do this in bulk:
for module in modules/*/* ; do
(
cd $module
if git diff --exit-code metadata.json ; then
git commit -m 'Mark compatible with puppetlabs/stdlib 7.x' metadata.json
fi
)
doneOf course you can expand the loop with commands like git push origin HEAD -u
and hub pull-request --no-edit to create bulk pull requests.
If you are used to a traditional GitHub Fork and PR model, then you may run into a couple of issues when using this repository.
You may have a case where you work with different communities where they all
name their modules puppet-<module_name>. Obviously, forking all of these and
keeping track of them is extremely difficult, particularly when GitHub does not
have the concept of subgroups.
In this case, we are going to assume that you have named your module
<username>/pupmod-<author>-<module_name>.
If your username is gituser and the author of the module is voxpupuli, and
the module name is firewalld then the full name would be
gituser/pupmod-voxpupuli-firewalld.
NOTE: This is NOT required, but may be useful in the situation noted above.
To work with the forked module, you will need to do the following:
- Add your forked module name to the
managed_modules.ymlfile - Tell
msyncexplicitly where to find your modulebundle exec msync -n <username> -f pupmod-<author>-<module_name> --noop
We currently require all commits to be signed with GPG, so please configure
your git client properly. Let us know if you need some help. We're also
reachable via our IRC channel #voxpupuli on freenode.
If you provide a patch that effects our modules, please test it on a single
module and link the pull request from that specific module to the PR on
the modulesync_config repository.
- Update the version in
moduleroot/.msync.yml.erb - export
GITHUB_CHANGELOG_TOKEN='*your token*' - bundle exec rake changelog