omnibus 5.6.6 → 5.6.8
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/Gemfile +0 -3
- data/lib/omnibus/version.rb +1 -1
- data/omnibus.gemspec +2 -4
- metadata +9 -46
- data/.expeditor/config.yml +0 -31
- data/.expeditor/update_version.sh +0 -12
- data/.github/CODEOWNERS +0 -3
- data/.github/ISSUE_TEMPLATE.md +0 -24
- data/.github/PULL_REQUEST_TEMPLATE.md +0 -16
- data/.gitignore +0 -151
- data/.rspec +0 -2
- data/.travis.yml +0 -26
- data/CHANGELOG.md +0 -802
- data/MAINTAINERS.md +0 -23
- data/VERSION +0 -1
- data/appveyor.yml +0 -39
- data/docs/Build Cache.md +0 -100
- data/docs/Building on Debian.md +0 -61
- data/docs/Building on OSX.md +0 -92
- data/docs/Building on RHEL.md +0 -75
- data/docs/Building on Windows.md +0 -57
- data/features/commands/build.feature +0 -42
- data/features/commands/clean.feature +0 -21
- data/features/commands/list.feature +0 -16
- data/features/commands/manifest.feature +0 -146
- data/features/commands/new.feature +0 -8
- data/features/commands/publish.feature +0 -15
- data/features/commands/version.feature +0 -12
- data/features/step_definitions/generator_steps.rb +0 -56
- data/features/support/env.rb +0 -15
- data/lib/omnibus/generator_files/.kitchen.local.yml.erb +0 -10
- data/lib/omnibus/generator_files/.kitchen.yml.erb +0 -44
data/MAINTAINERS.md
DELETED
@@ -1,23 +0,0 @@
|
|
1
|
-
# Maintainers
|
2
|
-
|
3
|
-
This file lists how the `omnibus` project is maintained.
|
4
|
-
|
5
|
-
When making changes to the system, you need two maintainers to provide a :+1: on your pull request. Additionally, you need to not receive a veto from a Lieutenant or the Project Lead.
|
6
|
-
|
7
|
-
Check out [How Chef is Maintained](https://github.com/chef/chef-rfc/blob/master/rfc030-maintenance-policy.md#how-the-project-is-maintained) for details on the process, how to become a maintainer, lieutenant, or the project lead.
|
8
|
-
|
9
|
-
## Project Lead
|
10
|
-
|
11
|
-
- [Seth Chisamore](https://github.com/schisamo)
|
12
|
-
|
13
|
-
## Maintainers
|
14
|
-
|
15
|
-
- [Daniel DeLeo](https://github.com/danielsdeleo)
|
16
|
-
- [Jay Mundrawala](https://github.com/jaym)
|
17
|
-
- [Kartik Null Cating-Subramanian](https://github.com/ksubrama)
|
18
|
-
- [Lamont Granquist](https://github.com/lamont-granquist)
|
19
|
-
- [Scott Hain](https://github.com/scotthain)
|
20
|
-
- [Seth Vargo](http://github.com/sethvargo)
|
21
|
-
- [Steven Danna](https://github.com/stevendanna)
|
22
|
-
- [Thom May](https://github.com/thommay)
|
23
|
-
- [Yvonne Lam](http://github.com/yzl)
|
data/VERSION
DELETED
@@ -1 +0,0 @@
|
|
1
|
-
5.6.6
|
data/appveyor.yml
DELETED
@@ -1,39 +0,0 @@
|
|
1
|
-
version: "{build}"
|
2
|
-
|
3
|
-
os: Windows Server 2012 R2
|
4
|
-
platform:
|
5
|
-
- x64
|
6
|
-
|
7
|
-
environment:
|
8
|
-
matrix:
|
9
|
-
- RUBY_VERSION: 24
|
10
|
-
- RUBY_VERSION: 23
|
11
|
-
- RUBY_VERSION: 22
|
12
|
-
|
13
|
-
clone_folder: c:\projects\omnibus
|
14
|
-
clone_depth: 1
|
15
|
-
skip_tags: true
|
16
|
-
branches:
|
17
|
-
only:
|
18
|
-
- master
|
19
|
-
|
20
|
-
install:
|
21
|
-
- SET PATH=C:\Ruby%RUBY_VERSION%\bin;C:\Ruby23-x64\DevKit\mingw\bin;%PATH%
|
22
|
-
- echo %PATH%
|
23
|
-
- ruby --version
|
24
|
-
- gem --version
|
25
|
-
- gem install bundler -v 1.10.6 --quiet --no-ri --no-rdoc --force
|
26
|
-
- bundler --version
|
27
|
-
- cp C:\Ruby23-x64\DevKit\mingw\bin\bsdtar.exe C:\Ruby23-x64\DevKit\mingw\bin\tar.exe
|
28
|
-
- appveyor DownloadFile http://curl.haxx.se/ca/cacert.pem -FileName C:\cacert.pem
|
29
|
-
- set SSL_CERT_FILE=C:\cacert.pem
|
30
|
-
- git config --global user.email "clouseau@chef.io"
|
31
|
-
- git config --global user.name "Pink Panther"
|
32
|
-
|
33
|
-
build_script:
|
34
|
-
- bundle install
|
35
|
-
|
36
|
-
test_script:
|
37
|
-
- bundle exec rake unit
|
38
|
-
- bundle exec rake functional
|
39
|
-
- bundle exec rake acceptance
|
data/docs/Build Cache.md
DELETED
@@ -1,100 +0,0 @@
|
|
1
|
-
# The Omnibus Build Cache #
|
2
|
-
|
3
|
-
The omnibus project includes a project build caching mechanism that
|
4
|
-
reduces the time it takes to rebuild a project when only a few
|
5
|
-
components need to be rebuilt.
|
6
|
-
|
7
|
-
The cache uses git to snapshot the project tree after each software
|
8
|
-
component build. The entire contents of the project's `install_dir`
|
9
|
-
is included in the snaphot.
|
10
|
-
|
11
|
-
When rebuilding, omnibus walks the linearized component list and
|
12
|
-
replays the cache until the first item is encountered that needs to be
|
13
|
-
rebuilt. Items are rebuilt if the code changes (different version or
|
14
|
-
different git SHA) or if the build instructions change (edit to
|
15
|
-
config/software/$COMPONENT).
|
16
|
-
|
17
|
-
## Location of Cache Data ##
|
18
|
-
|
19
|
-
The default location of the cache (which is just a bare git
|
20
|
-
repository) is
|
21
|
-
`/var/cache/omnibus/cache/git_cache/$INSTALL_DIR`. You can
|
22
|
-
customize the location of the cache in the `omnibus.rb` config file
|
23
|
-
using the key `git_cache_dir`. For example:
|
24
|
-
|
25
|
-
git_cache_dir "/opt/omnibus-caches"
|
26
|
-
|
27
|
-
## How It Works ##
|
28
|
-
|
29
|
-
Omnibus begins by loading all projects (see
|
30
|
-
`lib/omnibus.rb#expand_software`). The dependencies of each project
|
31
|
-
are loaded using `recursively_load_dependency` to capture the
|
32
|
-
transitive dependencies of a given project dependency. The result is
|
33
|
-
that each project has a list of components in "install order" such
|
34
|
-
that all dependencies come before the things that depend on
|
35
|
-
them. Components are de-duplicated on the way in and not added if
|
36
|
-
already present (which will occur when two components share a common
|
37
|
-
dependency).
|
38
|
-
|
39
|
-
The actual build order is determined by `library.rb#build_order` which
|
40
|
-
does a small reordering to ensure that components that are explicitly
|
41
|
-
listed in the project file come last. Since the first cache miss
|
42
|
-
causes the system to rebuild everything further to the right in the
|
43
|
-
component list, you want to have your most frequently changed
|
44
|
-
components last to minimize rebuild churn.
|
45
|
-
|
46
|
-
Lightweight git tags are used as cache keys. After building a
|
47
|
-
component, a tag name is computed in `GitCache#tag`. The
|
48
|
-
tag name has the format `#{name}-#{version}-#{digest}` where name and
|
49
|
-
version map to the component that was just built and digest is a
|
50
|
-
SHA256 value. The digest is computed by string-ifying the name/version
|
51
|
-
pairs of all components built prior to this component (keeping the
|
52
|
-
order of course) and prepending the entire contents of the component's
|
53
|
-
`config/software/$NAME.rb` file. Important aspects of the cache key
|
54
|
-
scheme:
|
55
|
-
|
56
|
-
* A change in the order or in the name/version of component built
|
57
|
-
before the component will invalidate the cache key.
|
58
|
-
* A change in the component's software config (build instructions)
|
59
|
-
invalidates the cache. This is done conservatively; the entire file
|
60
|
-
contents are included in the digest computation so even a whitespace
|
61
|
-
change will invalidate the key.
|
62
|
-
* A change in the version of the component itself will invalidate the
|
63
|
-
key.
|
64
|
-
|
65
|
-
You can inspect the cache keys like this:
|
66
|
-
|
67
|
-
git --git-dir=$CACHE_PATH tag -l
|
68
|
-
|
69
|
-
You can manually remove a cache entry using `git tag --delete
|
70
|
-
$TAG`.
|
71
|
-
|
72
|
-
|
73
|
-
## Build Slaves ##
|
74
|
-
|
75
|
-
You can share the cache among build slaves using `git clone/fetch`.
|
76
|
-
|
77
|
-
Using git bundles is another option (if you're using Jenkins, the bundle
|
78
|
-
can be persisted as an artifact):
|
79
|
-
|
80
|
-
+ Backup: `git --git-dir=$CACHE_PATH bundle create $CACHE_BUNDLE --tags`
|
81
|
-
+ Restore: `git clone --mirror $CACHE_BUNDLE $CACHE_PATH`
|
82
|
-
|
83
|
-
(CACHE_BUNDLE is anywhere you're persisting the bundle to)
|
84
|
-
|
85
|
-
|
86
|
-
### Important Caveat ###
|
87
|
-
|
88
|
-
Note that Omnibus caches instructions *exactly as they will be executed*
|
89
|
-
(e.g. Omnibus caches `make -j 9`, it doesn't cache `make -j #{workers}`).
|
90
|
-
|
91
|
-
So, if you intend to share your build cache among slaves, you should ensure
|
92
|
-
that their build environments are identical (failing which you'll bust the
|
93
|
-
cache with commands that depend on the environment).
|
94
|
-
|
95
|
-
|
96
|
-
## Mac OS X Caveats ##
|
97
|
-
|
98
|
-
When running a build vm on OS X, note that you will likely run into
|
99
|
-
trouble if you attempt to locate your cache on your local
|
100
|
-
filesystem if it is not case sensitive.
|
data/docs/Building on Debian.md
DELETED
@@ -1,61 +0,0 @@
|
|
1
|
-
Building Omnibus Packages for Debian
|
2
|
-
====================================
|
3
|
-
This document details the steps and configurables for building DEB packages with Omnibus.
|
4
|
-
|
5
|
-
|
6
|
-
Building a .deb
|
7
|
-
---------------
|
8
|
-
### Requirements
|
9
|
-
Omnibus assumes the existence of the `fakeroot` and `dpkg-deb` command on the build system. The [omnibus cookbook](https://supermarket.getchef.com/cookbooks/omnibus) automatically handles this installation. If you are not using the Omnibus cookbook, you must install these packages manually or using another tool.
|
10
|
-
|
11
|
-
### Configurables
|
12
|
-
A number of project configuration values are taken into consideration for building Debian packages. These options are further described in the [`Project` documentation](http://www.rubydoc.info/github/chef/omnibus/Omnibus/Project).
|
13
|
-
|
14
|
-
These values are interpolated and evaluated using Omnibus' internal DEB templates. For 99% of users, these templates should be satisfactory. If you encounter an instance where Omnibus' ERB templates do not satisfy a use case, please open an issue.
|
15
|
-
|
16
|
-
Because of the unlikelihood of their necessity, Omnibus does not generate deb-related assets. If you find yourself in a situation where you need to generate highly-customized DEB assets, run the Omnibus new command with the `--deb-assets` flag:
|
17
|
-
|
18
|
-
$ omnibus new NAME --deb-assets
|
19
|
-
|
20
|
-
**If this is an existing project, be sure to answer "NO" when asked if you want to overwrite existing files!**
|
21
|
-
|
22
|
-
With the `--deb-assets` flag, Omnibus will generate the following "stock" resources in `resources/NAME/deb`:
|
23
|
-
|
24
|
-
- `conffiles.erb` - the list of configuration files
|
25
|
-
- `control.erb` - the Debian spec file
|
26
|
-
- `md5sums.erb` - the ERB for generating the list of file checksums
|
27
|
-
|
28
|
-
**You should only generate the DEB assets if you cannot set values using attributes!**
|
29
|
-
|
30
|
-
### DSL
|
31
|
-
You can further customize the behavior of the packager using the `package` DSL command in your project definition:
|
32
|
-
|
33
|
-
```ruby
|
34
|
-
# project.rb
|
35
|
-
name 'hamlet'
|
36
|
-
|
37
|
-
package :deb do
|
38
|
-
vendor 'Company <company@example.com>'
|
39
|
-
license 'Apache 2.0'
|
40
|
-
priority 'extra'
|
41
|
-
section 'databases'
|
42
|
-
signing_passphrase 'acbd1234'
|
43
|
-
end
|
44
|
-
```
|
45
|
-
|
46
|
-
Some DSL methods available include:
|
47
|
-
|
48
|
-
| DSL Method | Description |
|
49
|
-
| :------------------: | --------------------------------------------|
|
50
|
-
| `signing_passphrase` | The passphrase to sign the RPM with |
|
51
|
-
| `vendor` | The name of the package producer |
|
52
|
-
| `license` | The default license for the package |
|
53
|
-
| `priority` | The priority for the package |
|
54
|
-
| `section` | The section for this package |
|
55
|
-
|
56
|
-
If you are unfamiliar with any of these terms, you should just accept the defaults. For more information on the purpose of any of these configuration options, please see the DEB spec.
|
57
|
-
|
58
|
-
For more information, please see the [`Packager::DEB` documentation](http://www.rubydoc.info/github/chef/omnibus/Omnibus/Packager/DEB).
|
59
|
-
|
60
|
-
### Notes on DEB-signing
|
61
|
-
To sign an DEB, you will need a GPG keypair. You can [create your own signing key](http://www.madboa.com/geek/gpg-quickstart/) or [import an existing one](http://irtfweb.ifa.hawaii.edu/~lockhart/gpg/gpg-cs.html). Omnibus will automatically call `gpg` with arguments that assume the real name associated to the GPG key is the same as the name of the project maintainer as specified in your Omnibus config.
|
data/docs/Building on OSX.md
DELETED
@@ -1,92 +0,0 @@
|
|
1
|
-
Building Omnibus Packages for Mac OS X
|
2
|
-
======================================
|
3
|
-
This document details the steps and configurables for building omnibus packages on Mac OS X. Unlike Linux-based systems, the process for building a `.pkg` (and compressing with `.dmg`) may involve the customization of some assets.
|
4
|
-
|
5
|
-
|
6
|
-
Building a .pkg
|
7
|
-
---------------
|
8
|
-
In Mac OS X, a `.pkg` is a special file that is read by Installer.app that contains the set of instructions for installing a piece of software on a target system.
|
9
|
-
|
10
|
-
### Requirements
|
11
|
-
By default, Omnibus does not generate pkg-related assets. To generate the pkg assets, run the Omnibus new command with the `--pkg-assets` flag:
|
12
|
-
|
13
|
-
$ omnibus new NAME --pkg-assets
|
14
|
-
|
15
|
-
**If this is an existing project, be sure to answer "NO" when asked if you want to overwrite existing files!**
|
16
|
-
|
17
|
-
With the `--pkg-assets` flag, Omnibus will generate the following "stock" resources in `resources/NAME/pkg`:
|
18
|
-
|
19
|
-
- `background.png` - the background image for the installer. We recommend this
|
20
|
-
image has a light background color (otherwise, the text will be difficult to
|
21
|
-
read).
|
22
|
-
- `distribution.xml.erb` - the XML file for use during the `productbuild` command
|
23
|
-
- `license.html.erb` - the full HTML document for the license
|
24
|
-
- `welcome.html.erb` - the full HTML document for the welcome screen
|
25
|
-
|
26
|
-
You should use these stock files and templates as a starting point for building your custom pkg.
|
27
|
-
|
28
|
-
### DSL
|
29
|
-
By default, Omnibus will try to build a pkg package when executed on a Mac OS X operating system. You can further customize the behavior of the packager using the `package` DSL command in your project definition:
|
30
|
-
|
31
|
-
```ruby
|
32
|
-
# project.rb
|
33
|
-
name 'hamlet'
|
34
|
-
|
35
|
-
package :pkg do
|
36
|
-
identifier 'com.getchef.hamlet'
|
37
|
-
signing_identity 'acbd1234'
|
38
|
-
end
|
39
|
-
```
|
40
|
-
|
41
|
-
Some DSL methods available include:
|
42
|
-
|
43
|
-
| DSL Method | Description |
|
44
|
-
| :----------------: | --------------------------------------------|
|
45
|
-
| `identifier` | The `com.whatever` id for the package |
|
46
|
-
| `signing_identity` | The key to sign the PKG with |
|
47
|
-
|
48
|
-
For more information, please see the [`Packager::PKG` documentation](http://rubydoc.info/github/opscode/omnibus/Omnibus/Packager/PKG).
|
49
|
-
|
50
|
-
|
51
|
-
Building a .dmg
|
52
|
-
---------------
|
53
|
-
In Mac OSX, a `.dmg` is a compressed wrapper around a collection of resources, often including a `.pkg`. The possibilities for creating and customizing a DMG are endless, but Omnibus provides a"basic starter case that will generate a pretty DMG that contains the `.pkg` file it creates.
|
54
|
-
|
55
|
-
### Requirements
|
56
|
-
By default, Omnibus does not generate dmg-related assets. To generate the dmg assets, run the Omnibus new with the `--dmg-assets` flag:
|
57
|
-
|
58
|
-
$ omnibus new NAME --dmg-assets
|
59
|
-
|
60
|
-
**If this is an existing project, be sure to answer "NO" when asked if you want to overwrite existing files!**
|
61
|
-
|
62
|
-
With the `--dmg-assets` flag, Omnibus will generate the following "stock" resources in `resources/NAME/dmg`:
|
63
|
-
|
64
|
-
- `background.png` - the background image to use for the DMG. We recommend using
|
65
|
-
a high-resolution image that is slightly larger than the final length of your
|
66
|
-
window (as determined by the `dmg_window_bounds`)
|
67
|
-
- `icon.png` - a 1024x1024 @ 300 icon to use for the DMG. We will automatically
|
68
|
-
create an icns and scale to smaller sizes
|
69
|
-
|
70
|
-
You should use these stock files and templates as a starting point for building your custom dmg.
|
71
|
-
|
72
|
-
### DSL
|
73
|
-
By default, Omnibus will **not** try to build a compressed dmg. You can enable this compression using the `compress` DSL command in your project definition:
|
74
|
-
|
75
|
-
```ruby
|
76
|
-
# project.rb
|
77
|
-
name 'hamlet'
|
78
|
-
|
79
|
-
compress :dmg do
|
80
|
-
window_bounds '200, 200, 750, 600'
|
81
|
-
pkg_position '10, 10'
|
82
|
-
end
|
83
|
-
```
|
84
|
-
|
85
|
-
Some DSL methods available include:
|
86
|
-
|
87
|
-
| DSL Method | Description |
|
88
|
-
| :----------------: | --------------------------------------------|
|
89
|
-
| `window_bounds` | The size and location of the DMG window |
|
90
|
-
| `pkg_position` | The position of the pkg inside the DMG |
|
91
|
-
|
92
|
-
For more information, please see the [`Compressor::DMG` documentation](http://www.rubydoc.info/github/chef/omnibus/Omnibus/Compressor/DMG).
|
data/docs/Building on RHEL.md
DELETED
@@ -1,75 +0,0 @@
|
|
1
|
-
Building Omnibus Packages for RHEL
|
2
|
-
==================================
|
3
|
-
This document details the steps and configurables for building RPM packages with Omnibus.
|
4
|
-
|
5
|
-
|
6
|
-
Building a .rpm
|
7
|
-
---------------
|
8
|
-
### Requirements
|
9
|
-
Omnibus assumes the existence of the `rpmbuild` command on the build system. The [omnibus cookbook](https://supermarket.getchef.com/cookbooks/omnibus) automatically handles this installation. If you are not using the Omnibus cookbook, you must install the package manually or using another tool.
|
10
|
-
|
11
|
-
### Configurables
|
12
|
-
The following Project values are taken into consideration when building RPMs:
|
13
|
-
|
14
|
-
- `build_version`
|
15
|
-
- `config_file`
|
16
|
-
- `conflicts`
|
17
|
-
- `description`
|
18
|
-
- `exclude`
|
19
|
-
- `extra_package_files`
|
20
|
-
- `iteration`
|
21
|
-
- `maintainer`
|
22
|
-
- `package_name`
|
23
|
-
- `package_user`
|
24
|
-
- `package_group`
|
25
|
-
- `package_scripts_path`
|
26
|
-
- `replaces`
|
27
|
-
- `runtime_dependency`
|
28
|
-
- `url`
|
29
|
-
|
30
|
-
These options are further described in the [`Project` documentation](http://www.rubydoc.info/github/chef/omnibus/Omnibus/Project).
|
31
|
-
|
32
|
-
These values are interpolated and evaluated using Omnibus' internal RPM templates. For 99% of users, these templates should be satisfactory. If you encounter an instance where Omnibus' RPM templates do not satisfy a use case, please open an issue.
|
33
|
-
|
34
|
-
Because of the unlikelihood of their necessity, Omnibus does not generate rpm-related assets. If you find yourself in a situation where you need to generate highly-customized RPM assets, run the Omnibus new command with the `--rpm-assets` flag:
|
35
|
-
|
36
|
-
$ omnibus new NAME --rpm-assets
|
37
|
-
|
38
|
-
**If this is an existing project, be sure to answer "NO" when asked if you want to overwrite existing files!**
|
39
|
-
|
40
|
-
With the `--rpm-assets` flag, Omnibus will generate the following "stock" resources in `resources/NAME/rpm`:
|
41
|
-
|
42
|
-
- `rpmmacros.erb` - the macros file
|
43
|
-
- `signing.erb` - a Ruby script for signing RPMs
|
44
|
-
- `spec.erb` - the ERB for generating the spec
|
45
|
-
|
46
|
-
**You should only generate the RPM assets if you cannot set values using attributes!**
|
47
|
-
|
48
|
-
### DSL
|
49
|
-
You can further customize the behavior of the packager using the `package` DSL command in your project definition:
|
50
|
-
|
51
|
-
```ruby
|
52
|
-
# project.rb
|
53
|
-
name 'hamlet'
|
54
|
-
|
55
|
-
package :rpm do
|
56
|
-
signing_passphrase 'acbd1234'
|
57
|
-
end
|
58
|
-
```
|
59
|
-
|
60
|
-
Some DSL methods available include:
|
61
|
-
|
62
|
-
| DSL Method | Description |
|
63
|
-
| :------------------: | --------------------------------------------|
|
64
|
-
| `signing_passphrase` | The passphrase to sign the RPM with |
|
65
|
-
| `vendor` | The name of the package producer |
|
66
|
-
| `license` | The default license for the package |
|
67
|
-
| `priority` | The priority for the package |
|
68
|
-
| `category` | The category for this package |
|
69
|
-
|
70
|
-
If you are unfamiliar with any of these terms, you should just accept the defaults. For more information on the purpose of any of these configuration options, please see the RPM spec.
|
71
|
-
|
72
|
-
For more information, please see the [`Packager::RPM` documentation](http://www.rubydoc.info/github/chef/omnibus/Omnibus/Packager/RPM).
|
73
|
-
|
74
|
-
### Notes on RPM-signing
|
75
|
-
To sign an RPM, you will need a GPG keypair. You can [create your own signing key](http://www.madboa.com/geek/gpg-quickstart/) or [import an existing one](http://irtfweb.ifa.hawaii.edu/~lockhart/gpg/gpg-cs.html). Omnibus automatically generates an `.rpmmacros` config file for `rpmbuild` that assumes that the real name associated to the GPG key is the same as the name of the project maintainer as specified in your Omnibus config. You can override this by creating your own `.rpmmacros` using the steps above.
|
data/docs/Building on Windows.md
DELETED
@@ -1,57 +0,0 @@
|
|
1
|
-
Building Omnibus Packages for Windows
|
2
|
-
=====================================
|
3
|
-
This document details the steps and configurables for building omnibus packages on Windows. Unlike Linux-based systems, the process for building an `.msi` may involve the customization of some assets.
|
4
|
-
|
5
|
-
|
6
|
-
Building an .msi
|
7
|
-
----------------
|
8
|
-
In Windows, an `.msi` is a special executable that contains the set of instructions for installating a piece of software on a target system. Please note, Omnibus does not support the creation of `.exe` files.
|
9
|
-
|
10
|
-
### Requirements
|
11
|
-
By default, Omnibus does not generate msi-related assets. To generate the msi assets, run the Omnibus new command with the `--msi-assets` flag:
|
12
|
-
|
13
|
-
$ omnibus new NAME --msi-assets
|
14
|
-
|
15
|
-
**If this is an existing project, be sure to answer "NO" when asked if you want to overwrite existing files!**
|
16
|
-
|
17
|
-
With the `--msi-assets` flag, Omnibus will generate the following "stock" resources in `resources/NAME/msi`:
|
18
|
-
|
19
|
-
- `localization-en-us.wxl.erb` => File that contains the strings that are being used in the MSI user interface
|
20
|
-
- `parameters.wxi.erb` => File that contains the dynamic information needed for the MSI e.g. version numbers
|
21
|
-
- `assets/LICENSE.rtf` => License text in Rich Text Format that is displayed during MSI installation
|
22
|
-
- `assets/*.bmp` => Bitmaps that are displayed during installation
|
23
|
-
- `assets/*.ico` => Icons that are used in the system for your application
|
24
|
-
|
25
|
-
You should use these stock files and templates as a starting point for building your custom msi.
|
26
|
-
|
27
|
-
These files are XML files that are created based on Windows WIX Schema. By default they will package the files under configured `install_dir` and present a UI that lets users to choose an installation location for the packaged files. You can modify these XML files based on the [WIX documentation](http://wixtoolset.org/documentation/manual/v3/xsd/).
|
28
|
-
|
29
|
-
### DSL
|
30
|
-
By default, Omnibus will try to build an msi package when executed on a Windows operating system. You can further customize the behavior of the packager using the `package` DSL command in your project definition:
|
31
|
-
|
32
|
-
```ruby
|
33
|
-
# project.rb
|
34
|
-
name 'hamlet'
|
35
|
-
|
36
|
-
package :msi do
|
37
|
-
upgrade_code '2CD7259C-776D-4DDB-A4C8-6E544E580AA1'
|
38
|
-
parameters {
|
39
|
-
'KeyThing' => 'ValueThing'
|
40
|
-
}
|
41
|
-
end
|
42
|
-
```
|
43
|
-
|
44
|
-
Note that `upgrade_code` is **required** and will raise an exception if not defined! Once set, this value must persist for all future versions of your package. To generate a GUID in Ruby, run the following command:
|
45
|
-
|
46
|
-
```bash
|
47
|
-
ruby -r securerandom -e "puts SecureRandom.uuid"
|
48
|
-
```
|
49
|
-
|
50
|
-
Some DSL methods available include:
|
51
|
-
|
52
|
-
| DSL Method | Description |
|
53
|
-
| :----------------: | ------------------------------------------------|
|
54
|
-
| **`upgrade_code`** | The unique GUID for this package |
|
55
|
-
| `parameters` | And arbirtary list of key-value pairs to render |
|
56
|
-
|
57
|
-
For more information, please see the [`Packager::MSI` documentation](http://www.rubydoc.info/github/chef/omnibus/Omnibus/Packager/MSI).
|