| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
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>
|