| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Signed-off-by: Christopher A. Snapp <csnapp@chef.io>
|
| |
|
|
|
|
|
| |
This removes the verify/habitat pipeline by bringing windows and linux
verification tests into the default verify pipeline.
Signed-off-by: Christopher A. Snapp <csnapp@chef.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Lots of things changing in here. Let's take them in a possibly weird
order.
* do_prepare()
Move all the settng of build environment ..uh.. settings into the
prepare function. Notable things:
- GEM_HOME is set to a vendor directory under pkg_prefix so that all gem
installs (regardless of bundle install or gem install) will be
installed _there_. Expect to see all gems shipped with chef-client
under this directory.
- Multiple bundle config --local commands. These are executed in a
subshell after changing directory to the CACHE_PATH so that the
bundler configuration will be written out to a `.bundle/config` file
there. bundle commands will be run from this location later, so these
settings become effective for the duration of the build and obviate
the need for a _bundle helper function.
* pkg_bin_dirs=()
Add the `vendor/bin` directory (remember, vendor/ is where gems get
installed, so the binstubs created by the installation will appear here
in vendor/bin/) to the PATH of this package's runtime environment
because there are commands in there people sometimes want to run. They
won't be fast and they might end up with conflicts with gems installed
by the user or by downstream pacakges because they haven't been
appbundled.
* do_setup_environment()
These are environment variables we'll want set to these defaults at
runtime.
- GEM_PATH gets this package's gem installation directory pushed onto it
making the gems available at runtime regardless of whether bundle exec
is used.
- APPBUNDLER_ALLOW_RVM is a flag looked for by the binstubs generated by
appbundler. Setting this to "true" has nothing to do with RVM and
everything to do with asking the appbundled binstub to not wipe out
the carefully constructed `GEM_PATH` from this package and any
possible others that "publish" to the runtime environment that gems
are available within.
- SSL_CERT_FILE - trust the CA cert package from core, by default, but
downstream packages can override this if they like with something
custom.
* do_build()
Life is simpler in the build function now. Build environment is all
setup, so here we:
- bundle install to retrieve dependencies based on the Gemfile+.lock
- run the rake install for the project which builds and installs the
gems whose source are in this repo (chef, chef-bin, chef-config)
- for any gem installed via a git reference, we change to the source
directory and rake install it, too, to install it like any other gem
This results in a clean collection of all the required gems installed
like normal gems under "vendor/gems." With that directory on the
GEM_PATH, we don't need to care about whether the gems were installed by
path reference or via git.
* do_install()
OK. I fibbed about not needing to tell bundler anything else. For
install, we're going to generate the appbundled binstubs that lockdown
the versions of gems required by particular commands. appbundler uses
the project's Gemfile+lock to determine those version, so for the
install actions, we tell bundler via an environment variable that the
Gemfile to work with is over in CACHE_PATH. Then we iterate over the
names of gems we want appbundled binstubs for in this package. Those
will land in pkg_prefix/bin/.
Note: there's nothing to copy here during install because all the gem
install actions were targeting pkg_prefix/vendor so what we would copy
is here already.
* do_after()
Stuff to make the package smaller.
- We don't need the cached .gem artifacts.
- We don't need the cache of git repos retrieved by bundler (those gems
are installed at this point like any other gem.)
- We don't need to ship the gem API documentation. (I imagine we could
change our minds about this later.)
- We don't need the spec tests for all the gems ... except for our own
chef gem which, for Reasons, we keep the spec suite around for
post-build functional testing.
* pkg_deps()
Ruby comes with a version of bundler that works at the moment. We don't
have to risk conflicts between the version of Ruby this package depends
on and the version of Ruby core/bundler was built against.
Signed-off-by: Robb Kidd <robb@thekidds.org>
Signed-off-by: Christopher A. Snapp <csnapp@chef.io>
|
| |
|
|
| |
Signed-off-by: mwrock <matt@mattwrock.com>
|
| |
|
|
| |
Signed-off-by: mwrock <matt@mattwrock.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Chef needs some DLLs on Windows. Normally, the libraries get copied to
the directory where the current Ruby executable is located when
bundle install is run.
We don't want that in Habitat land. The Ruby executable lives in another
package and package namespace. We want the libraries included in *this*
package. So, here we copy the DLLs during plan build to a lib directory
within this package and set an environment variable to disable the copy
occuring during bundle install. We push the library path onto
RUBY_DLL_PATH to inform whichever Ruby interpreter that will be running
Chef where to find our DLLs.
Signed-off-by: Robb Kidd <robb@thekidds.org>
|
| |
|
|
|
|
|
|
|
| |
Needed to install the gems-from-git-repos first. Those are the least
likely to have missing dependencies. Then we move on to installing the
gems that live in subdirectories of this repo. Sometimes that fails for
non-obvious reasons, but a retry seems to succeed.
Signed-off-by: Robb Kidd <robb@thekidds.org>
|
| |
|
|
|
|
|
| |
Need these so the PowerShell script will exit when bare commands fail.
Otherwise the build just keeps truckin' and the errors just pile up.
Signed-off-by: Robb Kidd <robb@thekidds.org>
|
| |
|
|
| |
Signed-off-by: John Snow <thelunaticscripter@outlook.com>
|
| |
|
|
| |
Signed-off-by: John Snow <thelunaticscripter@outlook.com>
|
| |\
| |
| | |
Make the hab version check a full version check not just minor release
|
| | |
| |
| |
| | |
Signed-off-by: John Snow <thelunaticscripter@outlook.com>
|
| | |
| |
| |
| | |
Signed-off-by: John Snow <thelunaticscripter@outlook.com>
|
| | |
| |
| |
| |
| |
| | |
Thanks for pointing this out Ian
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| |/
|
|
|
|
| |
When we migrated to hugo the URLs changed a bit. Nothing ends in .html and we moved all the resources into their own dir.
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| |
|
|
| |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
|
|
|
|
|
| |
Test hosts haven't necessarily had "hab setup" run for \hab\bin to be on
the system PATH. For the purposes on this test, we would like that to be
the case. So, put Hab's bin directory at the start of the PATH and carry
on.
Signed-off-by: Robb Kidd <robb@thekidds.org>
|
| |
|
|
|
|
|
|
| |
The PowerShell scripts calling PowerShell scripts was apparently
swallowing the errors being thrown from inner layers. Check the error
level of those scripts and throw another error if need be.
Signed-off-by: Robb Kidd <robb@thekidds.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds a test PowersShell script to habitat/tests/ to run some simple
tests on executable version output and then run the functional specs
suite like the omnibus_test script does.
scripts/ci/verify-plan.ps1 will perform a throwaway build of
the plan under a "ci" origin and then run the test script upon the built
package.
The habitat/verify pipeline was updated to run the verify-plan.ps1 script.
Signed-off-by: Robb Kidd <robb@thekidds.org>
add Windows plan verification to verify-hab pipeline
Signed-off-by: Robb Kidd <robb@thekidds.org>
|
| |
|
|
|
|
|
|
| |
Tell ffi-yajl to use the C-extensions we know are there because we
depend on MRI. C is fast, y'know, and we don't need the FFI portability
for other Ruby runtimes.
Signed-off-by: Robb Kidd <robb@thekidds.org>
|
| |
|
|
| |
Signed-off-by: Robb Kidd <robb@thekidds.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Based on Stuart Preston's work. Currently depends on the very large
ruby-plus-devkit package[1] that is a repackaging of
RubyInstaller+DevKit[2]. The DevKit is essentially MSYS2, which is its
own software distribution. It can get large. It is depended on currently
because it RubyInstaller+DevKit has been the most common Ruby on Windows
solution for build environment and library ecosystem.
Whatever Ruby this plan ultimately depends on is expected to have its
executables on the PATH and any gems it ships with (say, bundler, rake,
etc) added to GEM_PATH which is totally a thing a package can do in
SetupEnvironment and pushing directories onto GEM_HOME.
[1] https://bldr.habitat.sh/#/pkgs/chef/ruby-plus-devkit
https://github.com/chef/chef-plans/tree/master/ruby-plus-devkit
[2] https://rubyinstaller.org/about/comparison/
* bundle install'ing
With core/git not being fully capable of supporting a `bundle install`
because of semi-hardcoded paths to binaries, git is baked into the
"devkit" portion of Chef's chef/ruby-plus-devkit.
That means `bundle install` works, so this build uses a pattern
established in the chef omnibus software definition:
1. bundle install the Ruby dependencies
2. gem install the local gems
3. install the git-ref'd gems
At the end of these steps, all the gems are "installed" in the standard
directories under GEM_HOME/gems and binstubs are in GEM_HOME/bin.
* add the other Ruby binstubs to the PATH
Gems got their bundle/gem installed binstubs placed in GEM_HOME/bin
a.k.a vendor/bin. That path has been added to the package's bin paths
for use in the build and later in testing.
Appbundler is executed in Invoke-Install to create our precisely-pinned
binstubs for only the gems that supply executables we expect users of
chef-client to use. Those appbundled binstubs are placed into the
package's bin directory under $pkg_prefix/bin.
While the binstubs under vendor/bin aren't locked down with appbundler,
they're worth having on the PATH, particularly for testing the build.
* Trimming the Fat
Remove many of the byproducts of gems that appear in $pkg_prefix. Some
C-extension build logs. Other gems' spec directories. We keep the chef
gem's spec directory because we will be testing builds with the
functional portion of the test suite.
* Stripping the FS_ROOT
The studio's FS_ROOT appears in the Gemfiles generated by appbundler.
Added a function to remove the build environment's FS_ROOT from a given
file. Currently only using it on the chef gem's Gemfile so that it
can be used with `bundle install` and `bundle exec` to test the build.
* build in "${HAB_CACHE_SRC_PATH}/${pkg_dirname}"
"${HAB_CACHE_SRC_PATH}/${pkg_dirname}" is $CACHE_PATH, but we can't use
CACHE_PATH directly because it seems the Windows plan build script
doesn't actually set that variable unless pkg_version is computed and
updated; probably a bug, need to investigate.
Mainly opted for this to take advantage of the clean-room features of
builds done in the CACHE directory.
Use git to archive up only the version-controlled files and place that
archive where Hab would normally download a source artifact. Set the
$pkg_filename so the plan build knows what to archive and unpack.
No-Op the Verify function because the archive "downloaded" was just
created.
For Install, set the location of the Gemfile for bundler via an
environment variable instead of a `bundle config --local` command so
that there is no need to clean up the generated `.bundle/config`.
* have the plan check for a minimum hab version
The Windows plan must be built with Hab version 0.85.0 or greater
because of its use of the -IsPath option when setting/pushing paths in
SetupEnvironment. This change adds a version check to the Begin build
callback to bail with an informative error message when the required
minimum version isn't present. Otherwise, the error that appears is
the slightly arcane:
```
An error occured in the build!
You cannot call a method on a null-valued expression.
At C:\hab\pkgs\core\hab-studio\0.83.0\20190712234514\bin\hab-plan-build.ps1:1447 char:5
+ $pathArray = $path.Split($separator)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : InvokeMethodOnNull
```
Co-authored-by: Stuart Preston <stuart@chef.io>
Co-authored-by: John Snow <thelunaticscripter@outlook.com>
Signed-off-by: Robb Kidd <robb@thekidds.org>
|
| |
|
|
| |
Signed-off-by: Salim Afiune <afiune@chef.io>
|
| |
|
|
| |
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| |
|
|
|
|
| |
These were moved when the scafolding was in this dir
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| |
|
|
| |
Signed-off-by: echohack <echohack@users.noreply.github.com>
|
| |
|
|
| |
Signed-off-by: Nathan Cerny <ncerny@gmail.com>
|
| |
|
|
| |
Signed-off-by: Nathan Cerny <ncerny@gmail.com>
|
| |
|
|
| |
Signed-off-by: Nathan Cerny <ncerny@gmail.com>
|
| |
|
|
| |
Signed-off-by: Scott Macfarlane <smacfarlane@chef.io>
|
| |
|
|
| |
Signed-off-by: Scott Macfarlane <smacfarlane@chef.io>
|
| |
|
|
|
|
| |
Also tidy up the config a bit
Signed-off-by: Thom May <thom@chef.io>
|
| |
|
|
|
|
| |
* Add a few config new settings
Signed-off-by: Elliott Davis <edavis@chef.io>
|
| |\
| |
| | |
use git archive to speed up putting source in place
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
git archive + standard unpack untar is faster than rsync and prevents
picking up a dirty working directory.
Also fixes an empty GEM_HOME set during do_build and trims some trailing
whitespace.
Signed-off-by: Robb Kidd <robb@thekidds.org>
|
| |/
|
|
|
|
| |
This will resolve an error that appears if this package is built and run
for development or personal use under a different origin.
Signed-off-by: Robb Kidd <robb@thekidds.org>
|
|
|
This is a simple initial habitat plan. It creates a chef-client service,
which uses chef-solo to run cookbooks that are located in the default
cache location.
To build it yourself:
* Install habitat
* `hab studio build`
You'll wind up with a habitat artifact in `results`.
Signed-off-by: Adam Jacob <adam@chef.io>
|
