omnibus 5.6.6 → 5.6.8

Sign up to get free protection for your applications and to get access to all the features.
@@ -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
@@ -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
@@ -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.
@@ -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.
@@ -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).
@@ -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.
@@ -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).