packaging 0.88.77 → 0.99.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
-SHA256:
-  metadata.gz: ae79e9e05a45482476a6cdac7888cdf1aca7bbd6f80ef9bd5502a0f143512c84
-  data.tar.gz: e6534c76f98302001bdf1d5c8c2e8f5e343ee6cc05a5c857e77995c4a4ed2711
+SHA1:
+  metadata.gz: 60597eac7cb43a07b9c9c5f2e0446eeb97741697
+  data.tar.gz: 4b2493e3dac7fc620c221f29207c1aac0c4628d3
 SHA512:
-  metadata.gz: 9fa1398a9659ff420d3c2b32cf74de533acff812748531ecf1ca1c01fb1b97039a72932a54656f86749720c0986df941f39beaf43c7820656249331328a1fe69
-  data.tar.gz: ccc856e8484a179b903857c7a241eb5dd33888bfc4ba975bb5497484c02dc435d88e694aa9c3880eda19f8be4e4d4465d0c301ca1f1965c737e696c2f2f93bf3
+  metadata.gz: 945d03dbfe203b4ce43210494fba3da11c365064e54d014d5d2a04f1c42704295a355b0a1bd6a8b1f7b63388b4210db71d8b463b9d388a9ddc1b0d52a6f4bcce
+  data.tar.gz: 0f6e50d73f6d91d9666b49ff6e7a5a8019045c9cfb190a5c0ead9c04d341a5375e95d180bf2560511c404f860a6cedb10a4be4470a9cc717c5a331de61026492

data/README.md

@@ -36,12 +36,12 @@ as well as several closed-source projects, including
 * console-auth
 * console
 
-Generally speaking, the packaging repo should be compatible with ruby >= 2.0.0
-rake ~> 12.3. To pull the packaging tasks into your source repo,
-do a `bundle install`. This will install the packaging gem and all its
-dependencies. Packaging's rake tasks will be made available by running any rake
-command, e.g. `bundle exec rake -T`. The tasks are generally grouped into two
-categories, `package:` namespaced tasks and `pl:` namespaced tasks.
+Generally speaking, the packaging repo should be compatible with ruby 1.8.7,
+ruby 1.9.3 and rake 0.9.x. To pull the packaging tasks into your source repo,
+do a `rake package:bootstrap`. This will clone this repo into the ext directory
+of the project and make many packaging tasks available. The tasks are
+generally grouped into two categories, `package:` namespaced tasks and `pl:`
+namespaced tasks.
 
 ## `package:` tasks
 `package:` namespaced tasks are general purpose tasks that are set up to use
@@ -51,8 +51,7 @@ the building host, and any dynamically generated dependencies may result in
 packages that are only suitable for the OS/version of the build host. However,
 for rolling one's own debs and rpms or for use in environments without many
 OSes/versions, this may work just fine. To build an rpm using the packaging
-repo, do a `bundle exec rake package:rpm`. To build a deb, use `bundle exec rake
-package:deb`.
+repo, do a `rake package:rpm`. To build a deb, use `rake package:deb`.
 
 ## `pl:` tasks
 `pl:` namespaced tasks rely on a slighly more complex toolchain for packaging
@@ -76,32 +75,32 @@ separating these data and tasks out is to refrain from presenting by
 default yet more Puppet-specific tasks that aren't generally consumable by
 everyone. To build a deb from a local repository using a `pl` task, ssh into a
 builder (e.g., one stood up using the modules detailed below) and clone the
-source repo, e.g. puppet. Then, run `bundle install` and `bundle exec rake pl:deb`
-to create a deb, and `bundle exec rake pl:mock` to make an rpm (on a debian or
-redhat host, respectively).
+source repo, e.g. puppet. Then, run `rake package:bootstrap` and `rake pl:deb`
+to create a deb, and `rake pl:mock` to make an rpm (on a debian or redhat host,
+respectively).
 
 ## `pe:` tasks
-There is also a `pe:` namespace, for the building of Puppet Labs' Puppet
-Enterprise packages that have been converted to using this repo. The `pe:` tasks
-rely heavily on PL internal infrastructure, and are not generally useful outside
-of this environment. To create packages, in the source repository run `bundle
-install`, followed by `bundle exec rake pl:fetch`. These two commands install
-the packaging gem and pull in the additional data needed for PE building (see
-`pl:fetch` notes above). Then, to make a debian package, run `bundle exec rake
-pe:deb`, and to make an rpm, run `bundle exec rake pe:mock`. There are also
-`pe:deb_all` and `pe:mock_all` tasks, which build packages against all shipped
-debian/redhat targets. The `pe:deb_all` task is not generally necessary for
-developer use for building test packages; the `pe:deb` task creates a package
-that will work against virtually all supported PE debian versions. The same is
-generally true for PE internal rpms, but because of variances in build macros
-for rpm, rpms should generally be built with `pe:mock_all`, and then the desired
-version installed, or by building only for a specific target. This is
-accomplished by passing MOCK=<mock> to the rake call, e.g. `bundle exec rake
-pe:mock MOCK=<mock>`. The available mocks are listed in
-`ext/build_defaults.yaml` after `final_mocks:`. For PE, the mocks are formatted
-as `pupent-<peversion>-<distversion>-<arch>`, e.g. `pupent-2.7-el5-i386`. To
-build for a specific target, set `MOCK=<mock>` to the mock that matches the
-target.
+There is also a `pe:` namespace, for the building of Puppet
+Labs' Puppet Enterprise packages that have been converted to using this repo.
+The `pe:` tasks rely heavily on PL internal infrastructure, and are not
+generally useful outside of this environment. To create packages, in the source
+repository run `rake package:bootstrap`, followed by `rake pl:fetch`. These two
+commands bootstrap the packaging environment and pull in the additional data
+needed for PE building (see `pl:fetch` notes above).  Then, to make a debian
+package, run `rake pe:deb`, and to make an rpm, run `rake pe:mock`. There are
+also `pe:deb_all` and `pe:mock_all` tasks, which build packages against all
+shipped debian/redhat targets. The `pe:deb_all` task is not generally necessary
+for developer use for building test packages; the `pe:deb` task creates a
+  package that will work against virtually all supported PE debian versions.
+  The same is generally true for PE internal rpms, but because of variances in
+  build macros for rpm, rpms should generally be built with `pe:mock_all`, and
+  then the desired version installed, or by building only for a specific
+  target.  This is accomplished by passing MOCK=<mock> to the rake call, e.g.
+  `rake pe:mock MOCK=<mock>`.  The available mocks are listed in
+  `ext/build_defaults.yaml` after `final_mocks:`.  For PE, the mocks are
+  formatted as `pupent-<peversion>-<distversion>-<arch>`, e.g.
+  `pupent-2.7-el5-i386`. To build for a specific target, set `MOCK=<mock>` to
+  the mock that matches the target.
 
 ## `:remote:` tasks
 There are also sub-namespaces of `:pl` and `:pe` that are
@@ -109,24 +108,22 @@ worth noting. First, the `:remote` namespace. Tasks under `:remote` perform
 builds remotely on internal builders from your local workstation. How they
 work:
 
-0) Run `bundle install` to install the packaging gem and its dependencies.
-
-1) Run `bundle exec pl:fetch` to obtain extra data from the build-data repo. The data
+1) Run `pl:fetch` to obtain extra data from the build-data repo. The data
 includes the hostnames of builders to use for packaging.
 
 2) Create a git bundle of the local workspace and tar it up.
 
 3) Create a build parameters file. The params file includes all the information
 about the build, including any values overridden with env vars, and the actual
-task to run, e.g. `bundle exec rake pl:deb`.
+task to run, e.g. `rake pl:deb`.
 
 4) scp the git bundle and build parameters file to a temporary directory on the
 builder hostname assigned to that particular package build type.
 
-5) ssh into the builder, untar the git bundle, clone it, and run `bundle
-install`.
+5) ssh into the builder, untar the git bundle, clone it, and run `rake
+package:bootstrap`.
 
-6) ssh into the builder, cd into the cloned repo, and run `bundle exec rake
+6) ssh into the builder, cd into the cloned repo, and run `rake
 pl:build_from_params PARAMS_FILE=/path/to/previously/sent/file`.
 
 7) Maintain the ssh connection until the build finishes, and rsync the packages
@@ -138,7 +135,7 @@ groups, e.g. to use mock on the builder, membership in the mock group. This is
 a major hurdle, and is resolved with the `jenkins` tasks below.
 
 ## legacy `:jenkins:` workflow tasks
-(Deprecated - see "dynamic jenkins task workflow" below)
+(Deprecated - see "dyamic jenkins task workflow" below)
 Jenkins tasks are similar to the `:remote:` tasks, but they do not require ssh
 access to the builders. They do require being on the local network - the
 jenkins instance that performs package builds is an internal server only,
@@ -209,18 +206,18 @@ the task are:
 
     cd git_repo
 
-      ### Install the packaging gem via Bundler
-      bundle install && bundle exec rake pl:fetch
+      ### Clone the packaging repo
+      rake package:bootstrap && rake pl:fetch
 
       ### Perform the build
-      bundle exec rake pl:load_extras pl:build_from_params PARAMS_FILE=$WORKSPACE/BUILD_PROPERTIES
+      rake pl:load_extras pl:build_from_params PARAMS_FILE=$WORKSPACE/BUILD_PROPERTIES
 
       ### Send the results
-      bundle exec rake pl:jenkins:ship["artifacts"]
+      rake pl:jenkins:ship["artifacts"]
 
       ### If a downstream job was passed, trigger it now
       if [ -n "$DOWNSTREAM_JOB" ] ; then
-        bundle exec rake pl:jenkins:post["$DOWNSTREAM_JOB"]
+        rake pl:jenkins:post["$DOWNSTREAM_JOB"]
       fi
 
 #################
@@ -261,18 +258,18 @@ analysis. Contents of this string are items which cannot be obtained from within
 the Jenkins job itself. Note that the Groovy postbuild script needed for metrics
 gathering is dynamically passed to each job.
 
-This first job clones the git bundle passed in as a parameter, then installs the
-packaging gem (bundle install) and for every cell in its matrix performs a
-package build for a specific target (e.g. bundle exec rake pl:deb
+This first job clones the git bundle passed in as a parameter, then clones the
+packaging repo (rake package:bootstrap) and for every cell in its matrix
+performs a package build for a specific target (e.g. rake pl:deb
 COW=base-lucid-i386.cow). Once all cells in the matrix complete (either succeed
-or fail), this job automatically triggers the second of the new jobs as a
-downstream job.
+or fail), this job automatically triggers the second of the new jobs
+as a downstream job.
 
 To receive an email notification from jenkins about the status of the packaging
 job, pass NOTIFY=<recipient> as an environment variable to the uber_build
 invocation, e.g.:
 
-bundle exec rake pl:jenkins:uber_build NOTIFY="foo@puppet.com bar@puppet.com"
+rake pl:jenkins:uber_build NOTIFY="foo@puppet.com bar@puppet.com"
 
 The second job is an automatic repository creation task for this git repo.
 Specifically, the job copies the git bundle from the packaging job and clones
@@ -361,6 +358,10 @@ side of this packaging repo. The rpm-side module,
 [puppetlabs-rpmbuilder](https://github.com/puppetlabs/puppetlabs-rpmbuilder),
 will set up an rpm builder.
 
+## Clean up
+To remove the packaging repo, remove the ext/packaging directory or run `rake
+package:implode`.
+
 ##Setting up projects for the Packaging Repo
 
 The packaging repo requires many project-side artifacts inside the ext
@@ -376,9 +377,48 @@ spec file, and an osx preflight and plist.
 
 The top level Rakefile or a separate task file in the project should have the following added:
 
+(this assumes RAKE\_ROOT is defined in the top-level Rakefile using something like the following)
+```ruby
+RAKE_ROOT = File.expand_path(File.dirname(__FILE__))
+```
+
 ```ruby
-require 'packaging'
-Pkg::Util::RakeUtils.load_packaging_tasks
+build_defs_file = File.join(RAKE_ROOT, 'ext', 'build_defaults.yaml')
+if File.exist?(build_defs_file)
+  begin
+    require 'yaml'
+    @build_defaults ||= YAML.load_file(build_defs_file)
+  rescue Exception => e
+    $stderr.puts "Unable to load yaml from #{build_defs_file}:"
+    raise e
+  end
+  @packaging_url  = @build_defaults['packaging_url']
+  @packaging_repo = @build_defaults['packaging_repo']
+  raise "Could not find packaging url in #{build_defs_file}" if @packaging_url.nil?
+  raise "Could not find packaging repo in #{build_defs_file}" if @packaging_repo.nil?
+
+  namespace :package do
+    desc "Bootstrap packaging automation, e.g. clone into packaging repo"
+    task :bootstrap do
+      if File.exist?(File.join(RAKE_ROOT, "ext", @packaging_repo))
+        puts "It looks like you already have ext/#{@packaging_repo}. If you don't like it, blow it away with package:implode."
+      else
+        cd File.join(RAKE_ROOT, 'ext') do
+          %x{git clone #{@packaging_url}}
+        end
+      end
+    end
+    desc "Remove all cloned packaging automation"
+    task :implode do
+      rm_rf File.join(RAKE_ROOT, "ext", @packaging_repo)
+    end
+  end
+end
+
+begin
+  load File.join(RAKE_ROOT, 'ext', 'packaging', 'packaging.rake')
+rescue LoadError
+end
 ```
 
 Also in ext should be two files, build_defaults.yaml and project_data.yaml (optional).
@@ -404,9 +444,9 @@ deb_build_mirrors:
 # Who is packaging. Turns up in various packaging artifacts
 packager: 'puppetlabs'
 # GPG key ID of the signer
-gpg_key: '4528B6CD9E61EF26'
+gpg_key: '7F438280EF8D349F'
 # Whether to require tarball signing as a prerequisite of other package building
-sign_tar: false
+sign_tar: FALSE
 # a space separated list of mock configs. These are the rpm distributions to package for. If a noarch package, only one arch of each is needed.
 final_mocks: 'pl-el-5-i386 pl-el-5-x86_64 pl-el-6-i386 pl-el-6-x86_64 pl-fedora-16-i386 pl-fedora-16-x86_64 pl-fedora-17-i386 pl-fedora-17-x86_64'
 # The host that contains the yum repository to ship to
@@ -422,10 +462,10 @@ apt_repo_path: '/opt/repository/incoming'
 # The host that stores the tarballs for downloading
 tar_host: 'downloads.puppetlabs.com'
 # Whether to present the gem and apple tasks
-build_gem: true
-build_dmg: true
+build_gem: TRUE
+build_dmg: TRUE
 # Whether to execute the rdoc rake tasks prior to composing the tarball
-build_doc: false
+build_doc: FALSE
 # Whether to kick of a dynamic msi build job along side the uber_build
 # If present, a dynamically generated jenkins job will be kicked off.
 # The automation in puppet_for_the_win is used to build the msi with the
@@ -447,9 +487,9 @@ build_msi:
     repo: 'git://github.com/puppetlabs/puppet-win32-ruby.git'
 # Whether to present the Solaris 11 IPS packaging tasks
 # This requires suitable IPS packaging artifacts in the project in ext/ips
-build_ips: false
+build_ips: FALSE
 # Whether this project is a PE project or not
-build_pe: false
+build_pe: FALSE
 # An optional task to execute pre-tarball composition. See the tasks in
 # the 'pretasks' directory
 pre_tar_task: 'package:vendor_gems'
@@ -462,7 +502,7 @@ author: 'Puppet'
 email: 'info@puppet.com'
 homepage: 'https://github.com/puppetlabs/hiera'
 summary: 'Light weight hierarchical data store'
-description: 'A pluggable data store for hierarchical data'
+description: 'A pluggable data store for hierarcical data'
 # file containing hard coded version information, if present
 version_file: '/lib/hiera.rb'
 # A string indicating the version strategy for the project (one of 'odd_even' or 'rc_final'), defaults to rc_final
@@ -617,11 +657,18 @@ files:
 * **package:apple**
 
     Use `PackageMaker` to create a pkg package inside a dmg. Requires 'sudo'
-    privileges. `build_dmg: true` must be set in `ext/build_defaults.yaml`.
+    privileges. `build_dmg: TRUE` must be set in `ext/build_defaults.yaml`.
     Packages are staged in ./pkg/apple. See the Mac packaging section of
     [Setting up projects for the Packaging
     Repo](https://github.com/MosesMendoza/packaging/tree/more_documentation#setting-up-projects-for-the-packaging-repo).
 
+* **package:bootstrap**
+
+    Clone the packaging repo into this project. This task isn't actually in the
+    packaging repo itself, but resides in the project. See [Setting up projects
+    for the Packaging
+      Repo](https://github.com/puppetlabs/packaging#setting-up-projects-for-the-packaging-repo).
+
 * **package:deb**
 
     Use `debbuild` to create a deb package and associated debian package
@@ -630,10 +677,17 @@ files:
 
 * **package:gem**
     Use the `rubygems/package_task` library to create a rubygem from the
-    repository. Requires `build_gem: true` and gem-related parameters be set in
+    repository. Requires `build_gem: TRUE` and gem-related parameters be set in
     `ext/build_defaults.yaml` and `ext/project\_data.yaml`. The gem is staged
     in `./pkg`.
 
+* **package:implode**
+
+    Remove the packaging repo entirely from the project. This task isn't
+    actually in the packaging repo itself, but resides in the project. See
+    [Setting up projects for the Packaging
+    Repo](https://github.com/puppetlabs/packaging#setting-up-projects-for-the-packaging-repo).
+
 * **package:ips**
 
     Use Solaris 11 pkg* tools to create a IPS package from the project.
@@ -663,8 +717,8 @@ files:
 * **pl:build_from_params**
 
     Invoke a build from a build parameters yaml file. The parameters file
-    should be created with `bundle exec rake pl:write_build_params`. The
-    settings in the build parameters file will override all values contained in
+    should be created with `rake pl:write_build_params`. The settings in the
+    build parameters file will override all values contained in
     `./ext/build_defaults.yaml` and `./ext/project_data.yaml`.
 
 * **pl:deb**
@@ -679,10 +733,10 @@ files:
 
 * **pl:deb_all***
 
-    The same as `bundle exec rake pl:deb`, but a package is built for every cow
-    listed in `ext/build_defaults.yaml` on the line `cows:<cows>`. The packages
-    and associated source artifacts are staged in `./pkg/deb/$distribution`,
-    where $distribution is the Debian/Ubuntu codename of the cow that was used to
+    The same as `rake pl:deb`, but a package is built for every cow listed in
+    `ext/build_defaults.yaml` on the line `cows:<cows>`. The packages and
+    associated source artifacts are staged in `./pkg/deb/$distribution`, where
+    $distribution is the Debian/Ubuntu codename of the cow that was used to
     build the package, e.g. "wheezy" or "precise."
 
 * **pl:ips**
@@ -851,11 +905,11 @@ files:
 
 * **pl:mock_all**
 
-    The same as `bundle exec rake pl:mock`, but a package is built for every
-    mock listed in `ext/build_defaults.yaml` on the line `mocks:<mocks>`.
-    Packages are staged in `./pkg/<repo_name>/(el | fedora)/$version/(i386 |
-    x86_64 | SRPMS)`. The subdirectories are dependent on the mock that is used.
-    The task assumes that the mock configurations are the standard Puppet mock
+    The same as `rake pl:mock`, but a package is built for every mock listed in
+    `ext/build_defaults.yaml` on the line `mocks:<mocks>`. Packages are staged
+    in `./pkg/<repo_name>/(el | fedora)/$version/(i386 | x86_64 |
+    SRPMS)`. The subdirectories are dependent on the mock that is used. The
+    task assumes that the mock configurations are the standard Puppet mock
     configurations that are generated by the
     [puppetlabs-rpmbuilder](https://github.com/puppetlabs/puppetlabs-rpmbuilder)
     module.