plan.sh was expanding $PATH at build time when writing out the inspec bin script. This is incorrect, the variable should be expanded at runtime.
Signed-off-by: James Stocks <jstocks@chef.io>
We don't have backslashes in our Gemfile so I'm not sure what it was
doing in the first place... AND, apparently the file wasn't there.
Signed-off-by: Ryan Davis <zenspider@chef.io>
* Remove Hab pkg deps in favor of OS binaries
This removes the runtime dependencies on Hab pkgs and instead modifies
the `PATH` environment variable to use the OS binaries where the InSpec
Habitat package is installed.
It should be noted that this is counter to what Habitat intends in most
cases. In general, it is preferable to use only Habitat packages as
runtime dependencies to get all the benefits that Habitat provides.
We elected not to do this for the InSpec Habitat package since the list
of binaries that would need to be installed to support all InSpec
resources would be prohibitively expensive (both in disk space and
network requirements). If you wish to use Habitat packaged binaries with
this package you can use `hab pkg install origin/my-binary --binlink`.
Signed-off-by: Jerry Aldrich <jerryaldrichiii@gmail.com>
* Modify Habitat install example to use `--binlink`
Signed-off-by: Jerry Aldrich <jerryaldrichiii@gmail.com>
* Add `core/git` runtime dep (used for fetching)
Signed-off-by: Jerry Aldrich <jerryaldrichiii@gmail.com>
This updates the included Habitat plan to do the following:
- Include binaries needed for certain resources (Example: `curl`)
- Use `gem install/build` instead of Bundler
- Use a wrapper binary to ensure GEM_HOME and GEM_PATH are correct
- Perform build/install steps in a cache directory instead of `/src`
Many thanks to @miah @tduffield
Signed-off-by: Jerry Aldrich <jerryaldrichiii@gmail.com>
The Habitat plan has been modified to support building from the repo
rather than relying on a gem being pushed to RubyGems. This allows
us to build current packages at every merge rather than only pushing to
Habitat Builder when we promote to stable.
This change also enables Expeditor to perform builds for us and removes
the dependency on the rake task as it is no longer needed.
Signed-off-by: Adam Leff <adam@leff.co>
In #1820 we made it so inspec would install the checked out source
version rather than the version from RubyGems.
This actually didn't work (though it wasn't apparent in a development
environment) because it used a relative path to bin/inspec that pointed
at /src/bin/inspec, which only exists if you're in a Habitat studio
started from the InSpec repo.
Revert back to getting the gem from RubyGems to avoid this problem and
have a working package.
Signed-off-by: Nathan L Smith <smith@chef.io>
These are kind of all over the place, but should improve things:
* Use the new `pkg_version` mechanism to set the version, and fail if
the VERSION file is not present
* Use inspec.io for the upstream url
* Remove pkg_source and it's associated callbacks; they aren't required
any more
* Alphabetize the deps list
* Remove duplicate coreutils from build deps
* Move environment variable setting to `do_prepare`
* Delete all binstubs in bin that aren't inspec
* Put the generated Gemfile in $CACHE_PATH so it doesn't stomp on the
developer's Gemfile
* Insert the SSL_CERT_FILE env var in the binstub (Fixes#1582)
* Use install instead of cp to drop off Gemfile.lock
* Build using `path: '$SRC_PATH'` instead of `'= $pkg_version'` in the Gemfile
* Disable `do_strip` to decrease build time and because we don't need it
Works for me on Habitat 0.23.
Since all the "building" is done now in `do_install`, it would be
possible to define a `do_check` that runs `inspec exec` on profiles to
verify inspec is working by running inspec.
Signed-off-by: Nathan L Smith <smith@chef.io>
Runtime of `hab pkg exec chef/inspec` changes the path for the inspec
runtime to match that of the inspec hab package. This makes it so tests
which need to execute things like `hab pkg path myorigin/mypath` in the
can profile/test can successfully execute the command.
Signed-off-by: Ryan Hass <rhass@users.noreply.github.com>
In #1454, we welcomed a newly-revamped JUnit formatter which has
a dependency on Nokogiri. Unfortunately, this had led us to problems
getting InSpec included in Chef omnibus builds (see chef/chef#5937)
because Chef is using Ruby 2.4.1 and the Nokogiri maintainers have
not yet released a windows binary gem that supports Ruby 2.4.x.
This has led to breaking builds in Chef's CI platform and would
block the acceptance of chef/chef#5937.
This change replaces Nokogiri use with REXML instead. While REXML
can be slower than Nokogiri, it does not require native extensions
and is supported on all Chef platforms.
Signed-off-by: Adam Leff <adam@leff.co>
Nokogiri is failing to build in the habitat artifact due to the lack
of libxml2 and libxslt. This brings them in as dependencies and also
properly configures bundler to use them.
Signed-off-by: Adam Leff <adam@leff.co>
The `rainbow` gem requires `rake` to build native extensions, and rake
is a development dependency for InSpec, not a runtime dependency.
This change adds the `rake` gem to the Habitat build Gemfile so we
can successfully build a Habitat artifact.
Signed-off-by: Adam Leff <adam@leff.co>
