From f6fc9ef65dbe1bc1c4d6bf6426e105bce6882561 Mon Sep 17 00:00:00 2001 From: Jan Kaluza Date: Fri, 24 Mar 2017 07:58:55 +0100 Subject: [PATCH] Try to build container-build's yaml --- testmodule.yaml | 203 ++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 179 insertions(+), 24 deletions(-) diff --git a/testmodule.yaml b/testmodule.yaml index f8caeca..9aaf4f7 100644 --- a/testmodule.yaml +++ b/testmodule.yaml @@ -1,36 +1,191 @@ +# Document type identifier document: modulemd +# Module metadata format version version: 1 data: - summary: A test module in all its beautiful beauty. - description: This module demonstrates how to write simple modulemd files And can be used for testing the build and release pipeline. + # Module name, optional + # Typically filled in by the buildsystem, using the VCS repository + # name as the name of the module. + # name: container-runtime + # Module update stream, optional + # Typically filled in by the buildsystem, using the VCS branch name + # as the name of the stream. + # stream: test + # Module version, integer, optional, cannot be negative + # Typically filled in by the buildsystem, using the VCS commit + # timestamp. Module version defines upgrade path for the particular + # update stream. + # version: 1 + # A short summary describing the module, required + summary: Automates deployment of containerized applications + # A verbose description of the module, required + description: > + Docker is an open-source engine that automates the deployment of any + application as a lightweight, portable, self-sufficient container that will + run virtually anywhere. + + Docker containers can encapsulate any payload, and will run consistently on + and between virtually any server. The same container that a developer builds + and tests on a laptop will run at scale, in production*, on VMs, bare-metal + servers, OpenStack clusters, public instances, or combinations of the above. + # Module and content licenses in the Fedora license identifier + # format, required license: - module: [ MIT ] - dependencies: - buildrequires: - base-runtime: master - requires: - base-runtime: master + # Module license, required + # This list covers licenses used for the module metadata, SPEC + # files or extra patches + module: + - MIT + # Content license, optional + # A list of licenses used by the packages in the module. + # This should be populated by build tools. + content: + - ASL 2.0 + # Extensible metadata block + # A dictionary of user-defined keys and values. + # Optional. Defaults to an empty dictionary. + # xmd: + # some_key: some_data + # Module dependencies, if any. Optional. + # TODO: Provides, conflicts, obsoletes, recommends, etc. + # TODO: Stream name globbing or regular expression support + buildrequires: + base-runtime: master + requires: + base-runtime: master + # References to external resources, typically upstream, optional references: - community: https://fedoraproject.org/wiki/Modularity - documentation: https://fedoraproject.org/wiki/Fedora_Packaging_Guidelines_for_Modules - tracker: https://taiga.fedorainfracloud.org/project/modularity + # Upstream community website, if it exists, optional + community: https://projectatomic.io + # Upstream documentation, if it exists, optional + documentation: http://www.projectatomic.io/docs/ + # Upstream bug tracker, if it exists, optional + tracker: https://github.com/projectatomic/docker + # Profiles define the end user's use cases for the module and consist + # of package lists of components to be installed by default if this + # module is enabled. The keys here are the profile names and contain + # package lists by component type. See the example. + # Optional, defaults to no profile definitions. + # TODO: Profiles deserve detailed documentation. profiles: + # The default profile, used unless any other profile was selected. + # Optional, defaults to empty lists. default: rpms: - - tangerine + - docker + # An example minimal profile only installing one component. + # Optional, just like any other profile. + # XXX: What happens if the system wants to use an undefined + # profile name? Should we fall back to "default" or just assume + # an empty list? + minimal: + # A verbose description of the module, optional + description: Minimal profile installing only the docker package. + rpms: + - docker + vim: + description: Profile for vim users which installs Dockerfile syntax support for vim. + rpms: + - docker + - docker-vim + zsh: + description: Profile for zsh users which installs completion. + rpms: + - docker + - docker-zsh-completion + full: + description: Install all packages. + rpms: + - docker + - docker-common + - docker-rhel-push-plugin + - docker-vim + - docker-zsh-completion + - docker-rhsubscription + - docker-v1.10-migrator + - docker-common + - docker-logrotate + - docker-lvm-plugin + - docker-novolume-plugin + # Module API + # TODO: Define more API types api: + # The module's public RPM-level API. + # A list of binary RPM names that are considered to be the + # main and stable feature of the module; binary RPMs not listed + # here are considered "unsupported" or "implementation details". + # In the example here we don't list the xyz package as it's only + # included as a dependency of xxx. However, we list a subpackage + # of bar, bar-extras. + # Optional, defaults to an empty list. rpms: - - perl-Tangerine - - tangerine + - docker + - docker-common + - docker-rhel-push-plugin + - docker-vim + - docker-zsh-completion + - docker-rhsubscription + - docker-v1.10-migrator + - docker-common + - docker-logrotate + - docker-lvm-plugin + - docker-novolume-plugin + # Module component filters + filter: ~ + # RPM names not to be included in the module. + # By default, all built binary RPMs are included. In the example + # we exclude a subpackage of bar, bar-nonfoo from our module. + # Optional, defaults to an empty list. + # rpms: + # - baz-nonfoo + # Functional components of the module, optional components: + # RPM content of the module, optional + # Keys are the VCS/SRPM names, values dictionaries holding + # additional information. + # TODO: Define architectures to build for rpms: - perl-List-Compare: - rationale: A dependency of tangerine. - ref: f25 - perl-Tangerine: - rationale: Provides API for this module and is a dependency of tangerine. - ref: f25 - tangerine: - rationale: Provides API for this module. - buildorder: 10 - ref: f25 + docker: + # Why is this component present. + # A simple, free-form string. + # Required. + rationale: This package carries the primary functionality. + # Use this repository if it's different from the build + # system configuration. + # Optional. + # repository: http://pkgs.fedoraproject.org/cgit/rpms/docker + # Use this lookaside cache if it's different from the + # build system configuration. + # Optional. + # cache: https://example.com/cache + # Use this specific commit has, branch name or tag for + # the build. If ref is a branch name, the branch HEAD + # will be used. If no ref is given, the master branch + # is assumed. + # Optional. + ref: f26 + buildorder: 2 + golang: + rationale: BR of docker. + ref: f26 + buildorder: 1 + + + # Module content of this module + # Included modules are built in the shared buildroot, together with + # other included content. Keys are module names, values additional + # component information. + # Optional + # modules: + # includedmodule: + # # Why is this module included? + # # Required + # rationale: Included in the stack, just because. + # # Link to VCS repository that contains the modulemd file + # # if it differs from the buildsystem default configuration. + # # Optional. + # repository: https://pagure.io/includedmodule.git + # # See the rpms ref. + # ref: somecoolbranchname + # # See the rpms buildorder. + # buildorder: 100