This repository has been archived by the owner on Jan 15, 2024. It is now read-only.
Preparation for 2.1 #189
Merged
Preparation for 2.1 #189
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
To evaluate the Puppet catalogue on the Puppet Master, the client
doesn't need `rubygems` as well. This was an ancient hack (maintained
over years) to avoid such a setup in test environments for Puppet such
as Vagrant.
Instead something like this might be implemented:
``` ruby
Vagrant.configure(2) do |config|
# ...
config.vm.provision :puppet do |puppet|
puppet.module_path = ['puppet', ...]
end
end
```
With the `manifests/default.pp`:
``` puppet
node default {
contain ::nodejs
package { ['ruby', 'rubygems']:
ensure => present,
} ->
Class['::nodejs']
}
```
It's now listed in `::nodejs::params` as sensitive default, but in edge-cases it might be helpful to specify a different directory than `/usr/local/node/node-default` as directory for the default nodejs instance.
…nside the module The `::nodejs::params` class shall only be used as container with sensitive defaults to provide a working setup on an average OS. It should never be referenced directly inside the module's code, instead `::nodejs` should pass it down to all internal APIs. This is not a breaking change and much rather a cosmetic change as it only affects private parts of the module and `::nodejs` has a parameter with a default value.
Please refer to the changelog and the readme for further information. Fixes #187
As requested it might be helpful to specify your own location for either
source or binary distribution. Possible cases where this might be needed
are e.g. corporate environments without internet access or to deploy a
patched/forked version of NodeJS to Puppet nodes.
As the NodeJS distribution provides several ways to index the available
versions, the source_server behaves different when used with a custom
server.
```
class { '::nodejs':
source => 'https://your-server.com/nodejs.tar.gz',
}
```
You can't specify a version, but you need to directly specify the source
ot be installed.
`make_install => true` can be used for source builds with Puppet as
well.
Fixes #185
Don't support EOLed stdlib versions anymore, introduce upper-bound version constraints in `metadata.json` to ensure no accidental breakage with new major releases.
RuboCop searches for all `.rubocop.yml` inside the cwd, also the (broken) one from `puppetlabs-stdlib` which has deprecated rules and requires extra gems that aren't used by this module.
Due to several changes inside to the dependencies in the module this is a rather drastic change. The module `puppetlabs-gcc` seems to be abandoned (Puppet 3.x only support, last commit in 2015) which broke an automated install with enabled dependency resolution (as done in beaker). The logic of the module is now directly in `::nodejs::instance::pkgs`. To automate such testing processesin the future, `beaker` has been introduced with `docker` as hypervisor (it's far more lightweight than a full-blown `vagrant` setup). Currently we only support Ubuntu 16.04 LTS in the testing matrix, but whenever distros start to conflict with this module, the test suite can be easily extended. As `PUPPET_VERSION` is interpreted by beaker as well the test suite has been split into two tasks (:test and :acceptance) as gem's version constraint will break APT while provisioning docker. Fixes #188
Pull Request Test Coverage Report for Build 586
💛 - Coveralls |
|
I have reasonable confidence that this should be safe to merge. Mainly because this doesn't change internal logic, but mainly makes it easier to maintain the code by reducing the build matrix, adding additional checks and removing, unneeded old parts. It might take some time until 2.1 though since I have a lot of other ideas/projects I want to work on in my (limited) free time, so let's see when I have sufficient time to implement #138 which should (finally) land in 2.1 :) |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a rather big changeset, for detailed descriptions of each change, please read the text blocks of the commit messages.
The main idea behind v2.1 is less to release a feature-rich release, but to cleanup (and deprecate) parts of the module to ease maintenance and future development. In order to achieve this, EOLed dependencies have been dropped and newer language features have been used. To allow CI to actually perform acceptance tests, beaker has been adopted.
I'll leave this PR open for some time to await feedback (and see if I actually want to have everything as-is), then I'll start to prepare 2.1 release.