Logic for building OpenDaylight's upstream Source RPMs.
-SRPM/RPM builds are supported for the following OpenDaylight major releases, as well as various daily builds:
-
-* Helium SR4
-* Lithium
-* Lithium SR1
-* Lithium SR2
-* Lithium SR3
-* Lithium SR4
-* Beryllium
-* Beryllium SR1
-
## Overview
OpenDaylight's Source RPMs (SRPMs) are built using the logic provided here.
Community Build System's Koji-based RPM build system. From there they are
built into ready-to-install noarch RPMs and hosted for consumption.
-Data that differs per-build is is defined in the `build_vars.yaml` YAML
+Data that differs per-build is defined in the `build_vars.yaml` YAML
configuration file. The build logic consumes that dynamic data, uses
JinJa2 templates to generate RPM spec files and builds the RPMs/SRPMs they
define.
## Vagrant Build Environment
-All SRPM builds are done in the included Vagrantfile. It provides a
-consistent, known-working and easily shared environment.
+The included Vagrantfile defines a consistent, known-working and easily
+shared environment. It supports both VM and container-based providers.
```
-[~/packaging/rpm]$ vagrant status
+$ vagrant status
Current machine states:
default not created (virtualbox)
-[~/packaging/rpm]$ vagrant up
-[~/packaging/rpm]$ vagrant ssh
+$ vagrant up
+$ vagrant ssh
[vagrant@localhost vagrant]$ ls /vagrant/
build.py build_vars.yaml cache connect.sh Vagrantfile <snip>
```
+### Docker provider
+
+The Vagrantfile defines a Docker provider, enabling easy access to build.py
+in a container. The general command format is:
+
+```
+$ vagrant docker-run -- <flags to build.py>
+```
+
+To pass 5.0 (Boron) as the version to build:
+
+```
+$ vagrant docker-run -- -v 5 0
+```
+
+Dockerfile can be also used directly to build container image:
+
+```
+$ docker build -t "odl_rpm" .
+$ docker run -v $(pwd):/build odl_rpm -v 5 0
+```
+
## Defining New RPMs
The dynamic aspects of a build, such as ODL and RPM version info, have all
The OpenDaylight major (element) version number of the release to build.
-For example, Hydrogen is 1.x.x, Helium is 2.x.x, Lithium is 3.x.x and
-so on down the periodic table.
+For example, Hydrogen is 1.x.x, Helium is 2.x.x, Lithium is 3.x.x and so on
+down the periodic table.
#### `version_minor`
are called "release versions". For a given OpenDaylight major.minor.patch
version, there will be one or more major.minor.patch-rpm_release RPMs.
-#### `rpm_disttag`
-
-Override build VM's disttag from `.el7.centos` to `.el7` per [expected norms][11].
-
-By default, the disttag RPM macro is determined at RPM build time by the
-`rpmbuild` tool. For our CentOS 7 Vagrantfile, this results in a disttag of
-`.el7.centos`. However, especially since we generate noarch RPMs, there's no
-technical reason to use `.el7.centos` instead of the more common `.el7` disttag.
-Per [recommendations from upstream CentOS packagers][11], seemingly mostly to
-avoid confusion, we're overriding the default `.el7.centos` to `.el7` for all
-current builds.
-
-#### `java_version`
-
-Java versions supported by this ODL release.
-
-Versions are specified as a range, in the format required by RPM spec files.
-
-For example: `>= 1:1.7.0`
-
#### `sysd_commit`
Version of ODL systemd unitfile to download and package in ODL RPM.
Examples include "Helium-SR4", "Lithium" and "Lithium-SR1".
+#### `download_url`
+
+The ODL RPM repackages the tarball build artifact produced by ODL's
+autorelease build, because building Java projects from source directly
+to RPMs is very difficult with current tooling. This is the URL to the
+tarball ODL build to repackage into an RPM.
+
#### `changelog`
Entry in the RPM .spec file's changelog for this RPM.
examples provided by existing build definitions closely. The `rpmbuild` tool
will fail and complain fairly clearly if the format isn't correct.
+### Testing Build Logic
+
+Some `build.py` logic is covered by Python unit tests.
+
+To execute them:
+
+```
+$ python -m unittest test_build
+```
+
## Building SRPMs/RPMs
The `build.py` helper script is used for building OpenDaylight SRPMs/RPMs.
another sandbox, then inspected.
The `build.py` helper script can build a set of SRPMs/RPMs based on provided
-version arguments or all defined builds.
+version arguments.
```
[vagrant@localhost ~]$ /vagrant/build.py -h
usage: build.py [-h] [-v [major minor patch rpm [major minor patch rpm ...]]]
- [-a]
optional arguments:
-h, --help show this help message and exit
-v [major minor patch rpm [major minor patch rpm ...]], --version [major minor patch rpm [major minor patch rpm ...]]
RPM version(s) to build
- -a, --all Build all RPMs
```
The `-v`/`--version` flag accepts a version number. Any build that matches
the match unique. For example, `build.py -v 2 4 0 1` could only match one
definition (Helium SR4, 2.4.0-1).
-To build all RPMs defined in `build_vars.yaml`, use `build.py -a`.
-
The `build.py` script uses the `cache/cache.py` script to handled downloading
and caching the artifacts required for the requested builds. Artifacts are
cached in the `packaging/rpm/cache/` directory.
[vagrant@localhost vagrant]$ ssh -p 8101 -o StrictHostKeyChecking=no karaf@localhost
Authenticated with partial success.
Password authentication
-Password:
-
- ________ ________ .__ .__ .__ __
- \_____ \ ______ ____ ____ \______ \ _____ ___.__.| | |__| ____ | |___/ |_
- / | \\____ \_/ __ \ / \ | | \\__ \< | || | | |/ ___\| | \ __\
- / | \ |_> > ___/| | \| ` \/ __ \\___ || |_| / /_/ > Y \ |
- \_______ / __/ \___ >___| /_______ (____ / ____||____/__\___ /|___| /__|
- \/|__| \/ \/ \/ \/\/ /_____/ \/
-
+Password:
+
+ ________ ________ .__ .__ .__ __
+ \_____ \ ______ ____ ____ \______ \ _____ ___.__.| | |__| ____ | |___/ |_
+ / | \\____ \_/ __ \ / \ | | \\__ \< | || | | |/ ___\| | \ __\
+ / | \ |_> > ___/| | \| ` \/ __ \\___ || |_| / /_/ > Y \ |
+ \_______ / __/ \___ >___| /_______ (____ / ____||____/__\___ /|___| /__|
+ \/|__| \/ \/ \/ \/\/ /_____/ \/
+
Hit '<tab>' for a list of available commands
and '[cmd] --help' for help on a specific command.
## Templates vs Macros
-This section documents _why_ we use the YAML+Py+JinJa2 design we do, whereas
-the sections above document _how_.
+This section documents *why* we use the YAML+Py+JinJa2 design we do, whereas
+the sections above document *how*.
Typically, RPM builds use the macro mechanism provided by RPM spec files
and the `rpmbuild` tool to customize specs for specific builds. This works
The specifics (YAML, Python, JinJa2) were chosen because of their use in
other tools used by [Int/Pack][15], like Packer, Ansible and Puppet.
-
[1]: http://cbs.centos.org/koji/
+
[2]: https://trello.com/c/cgQmevT8/209-additional-access-to-centos-cbs
+
[3]: https://bugs.centos.org/
+
[4]: https://bugs.centos.org/view.php?id=8879
+
[5]: https://wiki.centos.org/HowTos/CommunityBuildSystem#head-00dad77f5720f3a984b0fac9f9bacac52047f73f
+
[6]: https://wiki.opendaylight.org/view/User:Dfarrell07
+
[7]: https://wiki.centos.org/HowTos/CommunityBuildSystem
+
[8]: https://bugs.centos.org/view.php?id=9472
+
[9]: http://cbs.centos.org/repos/
+
[10]: https://github.com/opendaylight/integration-packaging/tree/master/rpm/example_repo_configs
+
[11]: https://bugs.centos.org/view.php?id=9098#c23768
+
[12]: https://wiki.opendaylight.org/view/Simultaneous_Release:Helium_Release_Plan#Schedule
+
[13]: https://wiki.opendaylight.org/view/Simultaneous_Release:Lithium_Release_Plan#Schedule
+
[14]: https://wiki.opendaylight.org/view/Simultaneous_Release:Beryllium_Release_Plan#Schedule
+
[15]: https://wiki.opendaylight.org/view/Integration/Packaging
+
[16]: https://git.opendaylight.org/gerrit/gitweb?p=integration/packaging.git;a=tree;h=refs/heads/master;hb=refs/heads/master
Code Review / integration / packaging.git / blobdiff