1. 18 Sep, 2015 1 commit
  2. 04 Aug, 2015 2 commits
  3. 10 Mar, 2015 2 commits
    • Steven Danna's avatar
      Add build_version and build_git_revision to manifest · d34a2ea5
      Steven Danna authored
      This commit adds the build_version and the build_git_revision to the
      version-manifest.  The goal of these additions is to make it possible
      to tag and generate a changelog for a given build using two
      version-manifest.json files and the omnibus project's source code
    • Steven Danna's avatar
      Add `omnibus changelog generate` command · e9292356
      Steven Danna authored
      ChangeLog-Entry: A new `omnibus generate changelog` command generates
      an opinionated CHANGELOG entry based on metadata in commit messages.
  4. 23 Feb, 2015 1 commit
    • Steven Danna's avatar
      Introduce version manifest features to opscode-omnibus · c0861466
      Steven Danna authored
      This changeset introduces the following features:
        - Ability to create a version manifest in a text format (intended
          for humans) without depending on omnibus-software. Users can use
          this feature by adding:
      to their project definition.
        - Ability to create a version manifest in a JSON format (intended
          for machines). Users can use this feature by adding:
      to their project definition.
        - Ability to ingest a user-provided JSON-formatted version manifest
          during the build process. The JSON manifest will be used to
          construct overrides for software versions and sources. Please see
          the following sections for more details
      * Manifest Ingestion
      Ingesting an externally created manifest is NOT intended to be the
      standard mode of operation for an omnibus built project. Most projects
      should continue to use the `default_version` method of software
      definitions and the `override` method of project definition to control
      which version of a software get built.
      This feature is included to support improvements to the build
      pipelines for opscode-omnibus (Chef Server) and other Chef Software,
      Inc managed projects by:
        - allowing the opscode-omnibus software to use floating constraints,
          ensuring new features in API services are immediately integrated
          into the Chef Server package.
      while still
        - allowing users to rebuild a specific version of an omnibus built
          project from source.
        - ensuring all versions of all software in a given build are captured
          in a format that can be commited to source control.
        - providing a possible base for automated generation of other
          release-related artifacts such as change logs.
      Chef Software, Inc reviewers should note that the manifest will NOT be
      ingested at any point in the standard build pipeline.
      * Text Manifest Format
      For backwards compatibility, the text version manifest is produced in
      exactly the same manner as the previous version manifest produced by
      * JSON Manifest Format v1
      The first version of the manifest format takes the following form:
          "manifest_format" : MANIFEST_FORMAT_NUMBER,
          "software" : {
          "SOFTWARE_NAME" : {
            "described_version": STRING(see below)
            "locked_version": STRING(see below)
            "locked_source": HASH(see below)
            "source_type": "path"|"url"|"git"|"project_local"
        - `described_version` is the user-specified version of the software
          (via default_version or an override) at the time of the build.
        - `locked_version` is the calculated version of the source artifact
          that was fetched. For git sources this will be a git ref and may
          differ from the described_version.
        - `locked_source` is the source parameters used to fetch the source
        - `source_type` specifies the type of source fetcher that was used.
      Only non-null fields are present in the manifest.  Software with a
      `project_local` source type may not have a source or either version
      field. Software with a `path` source type may not have a either
      version field.
      * Build Reproducibility
      When ingesting a manifest, omnibus will do the following:
      - Use the `locked_version` and `locked_source` when fetching the build
      - Proceed with the usual omnibus build procedures
      This procedure does NOT guarantee that a given build will produce a
      functionally equivalent artifact.  This is especially true for
      - projects using path or project_local based software
      - projects using software where the build steps also pull down new
      software (bundle install)
      - projects using software where the build steps produce different
      output depending on environmental factors (time, state of the build
      machine, etc)