2014/09/14
This bugfix release incorporates all fixes added in 1.2.4.
2014/09/11
(GH-178) Failing to fetch a source git repo can wipe out environments
When updating Git sources at the beginning of a deployment, if the fetch was interrupted r10k could cache an empty list of environments. This could cause r10k to remove all environments for that source. This was due to a method directly using a value that was supposed to be lazily evaluated and memoized. It has been fixed so that even if r10k cannot fetch a source it will still be able to deploy modules for environments, clean up removed environments, and correctly remove unmanaged environments.
(GH-186) Rescue SyntaxError when checking Puppetfile syntax
When a Puppetfile with invalid syntax is parsed it raises a SyntaxError,
and the r10k puppetfile check code was not specifically handling that.
Thus when checking an invalid file r10k was actually crashing and not
gracefully handling the error. This was fixed to cleanly rescue the SyntaxError,
optionally print stacktraces, and print an all ok message on success.
2014/07/27
This bugfix release incorporates all fixes added in 1.2.3.
2014/07/16
(GH-161) Deployments fail where a branch has \W in the git branch name
In 1.3.0 environment naming was partially reworked to allow better handling of per-environment deployment, but unfortunately this caused a regression where environments would be differently named in 1.3.0. This fix changes the environment deployment on a per-name basis to use the normalized name instead of the raw Git branch name.
This bugfix release also incorporates all fixes added in 1.2.2.
Thanks to Chris Spence for his work on this release.
2014/06/07
R10k can now dynamically generate enviroments based on SVN repositories. SVN repositories must SVN repositories must conform to the conventional SVN repository structure with the directories trunk/, branches/, and optionally tags/ in the root of the repository. The trunk/ directory is specifically mapped to the production environment, branches are created as environments with the name of the given branch.
Please note that since SVN support for environments should be considered preliminary and may still have some kinks to be worked out, so use it with caution in production.
When deploying modules with r10k deploy module <modules>, users can specify
the -e <environment> flag to update modules in a single environment.
Git sources can now tune how r10k behaves when it encounters a git branch with a non-word character. Valid values are 'correct_and_warn' which emits a warning and sanitizes the environment name, 'correct' which silently corrects the environment, and 'error' which emits an error and ignores the environment.
There are a lot of internal APIs in r10k that need to be improved or overhauled, and making changes in a backwards compatible manner has been impeding development on a number of important features. There's no indication that there are any consumers of the r10k internal APIs, and if that's the case then r10k doesn't help anyone by maintaining SemVer for its internal APIs.
As of 1.3.0, r10k is dropping guarantees about API compatibility for most of
the core functionality. The R10K::Task* classes were designed to be the
primary interface for external use and those will remain backwards compatible
for 1.x. However any code around configuration parsing, deployments, sources,
environments, and modules may have API changes in minor versions.
That being said, if you are using any of these APIs and you experience breakage, you're not out of luck. If an API change actually does affect you please report it as a bug and those specific APIs can probably be fixed up. Hopefully this will ease development of r10k while not making the lives of external developers too painful.
This allows the groundwork for allowing users to implement plugins for sources and environments. A real API specification for sources and environments has been started, and sources and environments can be defined at runtime. In the long run r10k will add a plugin system for loading additional code from Rubygems and other sources, so r10k will be extensible without requiring modifications to the source.
2014/09/14
(GH-188) Call puppet module tool install with --force for downgrades
2014/07/27
(GH-173) Fixed a bug with Ruby 1.8.7 with Pathname objects.
2014/07/16
(GH-165) r10k puppetfile only consumes handled command line options.
Previously, passing -v or other commands when running r10k puppetfile *
could result in this error:
r10k puppetfile install --help --trace
Error while running: #<RuntimeError: Unrecognized options: help>
This was due to overly greedy code passing in all options from the command line to the TaskRunner. This has been fixed so only known options are passed along, and options that aren't relevant (such as :verbose) will be ignored.
(GH-158) Log levels are now documented in the command line --help pages.
(GH-137) Git remotes are now correctly updated.
A regression in the Git remote handling meant that git remotes would never be properly updated when switching Git environments and modules from one remote to another, and the git alternates file was never updated properly. This has been fixed so that when the Git remote is updated, all references to the remotes and alternates will be updated.
(GH-163) All Git tags are deleted when switching Git remotes
Git tags cannot necessarily be transferred from one Git repository to another, so when a Git repo has its remotes changed all tags are deleted to prevent stale tags from overwriting tags from the new repo.
2014/04/21
(GH-93) r10k deploy subcommands now respect the --help flag.
(GH-100) The addition of a faster command execution library was POSIX centric, but there were a number of users that were running r10k on Windows, which brike their environments. Support for Windows has been re-added and Windows is now a supported platform for using the r10k puppetfile commands. Please note that r10k now requires Ruby 1.9.3 on Windows to function.
Thanks to Sam Kottler and Daniel Dreier for their their work on this release.
2014/03/07
Preliminary support for Puppetfile modules from SVN sources. SVN repositories can track the latest available revision or may be pinned to a specific revision.
Forge modules can now track the latest available version. This can be enabled by
setting the module version to :latest.
Git based Puppetfile modules can now be specified as branches, tags, and commits. When tags and commits are specified r10k can perform optimizations when updating the given repositories to reduce network accesses.
Command execution has been greatly improved. The old library for executing commands (systemu) had very high overhead and was 50 - 100 times slower than %x[] or fork/exec. It's been replaced with a custom process execution implementation.
Modules can swap out sources. When an existing module is changed from Forge to Git, for instance, the existing module will be removed before the new module is installed. (GH-30)
2014/02/27
Git repositories were not tracking their upstream remotes, repos should now properly update upstream changes.
Git reference clones now fetch their cache remotes immediately after the initial clone.
2014/02/08
Release Candidate 1 for 1.2.0
2014-02-24
This is a backwards compatible bugfix release.
- (GH-90) Multiple environments with the same name but with different sources were previously colliding and some environments were being ignored. This has been fixed and all environments should be deployed when updates are run.
Thanks to the following contributors for their their extraordinary patience and help in for chasing down GH-90:
- Andreas Ntaflos (antaflos)
- Igor Galić (igalic)
2014-01-26
This is a backwards compatible maintenance release.
- (GH-82) Added all git managed files, including README.markdown, CHANGELOG, and LICENSE to the gemspec for better compatibility with non-gem packages.
2014-01-06
This is a backwards compatible maintenance release.
- If Puppet and r10k are required in the same namespace, it's possible for the vendored copy of SemVer to conflict with the Puppet version. This was fixed by renaming the copy vendored in r10k and putting it under a namespace.
2013-12-11
This is a backwards compatible bugfix release.
- (GH-48) Environment prefixing always defaults to off. Users were already using r10k with multiple sources but in different directories, and prefixing breaks this behavior. Since this was a backwards incompatible change this has to be rolled back.
- (GH-64) Multiple sources in a single directory no longer purge each other.
Thanks to the following contributors for their help in 1.1.1:
- Stig Sandbeck Mathisen
- Gabriel M Schuyler
2013-09-30
This is a backwards compatible bugfix and feature release.
(GH-35) Puppetfiles can now specify a path to the moduledir, instead of assuming
'/modules'. It can be set with the Puppetfile moduledir directive. Note that
this is not compatible with librarian-puppet.
(GH-53) Multiple environment sources can now be specified in a single
directory. When multiple sources are specified, each environment will be
prefixed with the source name. This can be enabled and disabled with the
source prefix option.
(GH-45) Documentation has been greatly expanded.
(GH-56) New subcommand: r10k puppetfile check allows you to validate the
syntax of a Puppetfile.
(GH-66) Initial clones use git checkout when switching to a new branch
instead of just git reset; without this change it would look like the wrong
branch was checked out.
(GH-59) r10k can now pull from Pulp repositories for Forge based modules.
(GH-70) Handle unset HOME - in case that HOME is unset, assume that the current
user is root. This mainly occurs when r10k is being run as the prerun command
under Puppet.
The method mocking framework has been switched from mocha to rspec-mocks. Mocha is notoriously bad about breaking changes between versions and rspec-mocks is very robust, so Mocha has been ripped out and dropped as a dependency.
Rspec expectations now use the expect(thing).to syntax instead thing.should
A quasi settings framework has been extracted to make application settings less bad. In the long term a general application framework will be extracted from r10k to handle generic 'application' problems like this, but for now the settings framework is the way to handle singleton data.
R10K:Git::Cache object memoization has been extracted into a standalone class instead of being grafted onto the class. All hail the single responsibility principle!
R10K::Module code has been refactored. There's now a real base class instead of a hacky mixin with some metadata magic on top.
Thanks to the following contributors for their help in 1.1.0:
- Alex Linden Levy
- Abhay Chrungoo
- Adam Vessey
- Chuck Schweizer
- Elias Probst
- Greg Baker
- Jochen Schalanda
- Theo Chatzimichos
2013-05-30
This is a backwards incompatible bugfix and feature release.
The configuration file format of 0.0.9 should be compatible with 1.0.0, and any issues with that should be considered a bug.
A longstanding issue was confusion between symbols and strings in r10k.yaml (GH-18). To resolve this, symbols and strings will be treated equally and should produce the same behavior. In the long run, symbols will probably be deprecated for the sake of conformity.
A number of commands have been renamed. They still but will emit a deprecation
warning and will redirect to the new command implementation. The only
exceptions is the are the r10k environment cache and r10k environment stale
commands, but they were pretty much useless anyways.
Log level verbosity can now be specified by level name instead of level number.
If --verbose is passed without a level, it will set the log level to info.
r10k can be used to deploy modules from a standalone Puppetfile. See
r10k puppetfile for more information.
Modules without a version in the format of 'foo/bar' will be assumed. (GH-21)
r10k handles versioning according to SemVer; since this is a major release this is a backwards incompatible API change. It's unlikely that this has had any extensions written on top of it, but if you have, then heads up. However, all versions of 1.x should be backwards compatible.
A number of bugs were due to underlying architecture flaws. Part of 1.0.0 has been a significant architectural overhaul, so on top of all of the above changes there should be a lot of other bugs that have been fixed.