-
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: with_text_manifest to their project definition. - Ability to create a version manifest in a JSON format (intended for machines). Users can use this feature by adding: with_json_manifest 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 omnibus-software. * JSON Manifest Format v1 The first version of the manifest format takes the following form: ```json { "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 artifact. - `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 artifact. - 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)
c0861466