| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Signed-off-by: Matt Wrock <matt@mattwrock.com>
|
| |
|
|
| |
Signed-off-by: John McCrae <john.mccrae@progress.com>
|
| |
|
|
|
|
|
|
|
| |
This is a combination of 64 commits, the originals were mostly
repeating one-line messages so that history has not been kept here.
Signed-off-by: Thomas Powell <thomas.powell@progress.com>
Signed-off-by: Marc Paradise <marc@chef.io>
Signed-off-by: John McCrae <john.mccrae@progress.com>
|
| |
|
|
| |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
|
|
| |
Ship on Ruby 3 everywhere
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| |
|
|
|
|
|
| |
multi-job bundle install is the default in the next release, but for now
we should make sure we set it everywhere.
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| |
|
|
| |
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>
|
| |
|
|
| |
Signed-off-by: John Snow <thelunaticscripter@outlook.com>
|
| |
|
|
|
|
|
|
| |
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>
|
