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 update
bundle 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/push
This 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-requests
You 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-checkouts
We 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_diffs
You 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-dependencies
If 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_deps
If 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.json
You 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
)
done
Of 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.yml
file - Tell
msync
explicitly 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