1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
2 .. SPDX-License-Identifier: CC-BY-4.0
3 .. (c) Open Platform for NFV Project, Inc. and its contributors
5 .. _release-automation:
11 This page describes how projects can take advantage of the release
12 automation introduced in Fraser for creating their stable branch, and
13 stable branch Jenkins jobs.
15 It also describes the structures of the ``releases`` directory and the
18 Stable Branch Creation
19 ----------------------
21 If your project participated in the last release (beginning with
22 Euphrates), perform the following steps:
24 #. Copy your project's release file to the new release directory. For
27 cp releases/euphrates/apex.yaml releases/fraser/apex.yaml
29 #. For projects who are participating the in the stable release process for
30 the first time, you can either copy a different project's file and
31 changing the values to match your project, or use the following
32 template, replacing values marked with ``<`` and ``>``:
37 project: <opnfv-project-name>
38 project-type: <opnfv-project-type>
42 - name: stable/<release>
44 <project-repo>: <git-sha1>
46 #. Modify the file, replacing the previous stable branch name with the
47 new release name, and the commit the branch will start at. For
57 #. If your project contains multiple repositories, add them to the list
58 of branches. They can also be added later if more time is needed
59 before the stable branch window closes.
69 apex-puppet-tripleo: <git-sha1>
71 #. Git add, commit, and git-review the changes. A job will be triggered
72 to verify the commit exists on the branch, and the yaml file follows
73 the scheme listed in ``releases/schema.yaml``
75 #. Once the commit has been reviewed and merged by Releng, a job will
76 be triggered to create the stable branch Jenkins jobs under
80 Stable Release Tagging
81 ----------------------
88 The following is a description of fields in the Release file, which are
89 verified by the scheme file at ``releases/schema.yaml``
92 Project team in charge of the release.
95 Release model the project follows.
97 One of: stable, non-release
100 Classification of project within OPNFV.
102 One of: installer, feature, testing, tools, infra
105 (Optional) Upstream OpenStack project assocated with this project.
108 List of released versions for the project.
111 Version of the release, must be in the format ``opnfv-X.Y.Z``.
114 Combination of repository and git hash to locate the release
119 opnfv-project: f15d50c2009f1f865ac6f4171347940313727547
122 List of stable branches for projects following the ``stable`` release-model.
125 Stable branch name. Must start with the string ``stable/``
128 Same syntax as ``location`` under ``releases``
131 Link to release notes for the projects per-release.
137 * ``create_branch.py -f <RELEASE_FILE>``
139 Create branches in Gerrit listed in the release file.
141 Must be ran from the root directory of the releng repository as the
142 release name is extracted from the subdirectory under ``releases/``
144 The Gerrit server can be changed by creating a ``~/releases.cfg``
145 file with the following content::
148 url=http://gerrit.example.com
150 This will override the default configuration of using the OPNFV
151 Gerrit server at https://gerrit.opnfv.org, and is primarily used for
154 * ``create_jobs.py -f <RELEASE_FILE>``
156 Modifies the jenkins job files for a project to add the stable branch
157 stream. Assumes the jenkins jobs are found in the releng repository
158 under ``jjb/<project>/``
160 * ``verify_schema -s <SCHEMA_FILE> -y <YAML_FILE>``
162 Verifies the yaml file matches the specified jsonschema formatted
163 file. Used to verify the release files under ``releases/``