Curently, the dist and mock configurations are hardcoded in the
Makefile to be el8 and epel-7-x86_64, respectively. This commit
allows the user to override those settings using the DIST and
MOCK_CONFIG environment variables, falling back to the current
defaults if not set.
This provides additional flexibility when building the RPM directly
from the repository.
Signed-off-by: Javier Peña <jpena@redhat.com>
Change the default dist value to el8 for consistency, since many of the
upcoming ceph-ansible builds will be based on RHEL 8.
Signed-off-by: Ken Dreyer <kdreyer@redhat.com>
Fix a typo in `tag` target, double quote are missing here.
Without them, the `make tag` command fails like this:
```
if [[ "v3.0.35" == ]]; then \
echo "e5f2df8 on stable-3.0 is already tagged as v3.0.35"; \
exit 1; \
fi
/bin/sh: -c: line 0: unexpected argument `]]' to conditional binary operator
/bin/sh: -c: line 0: syntax error near `;'
/bin/sh: -c: line 0: `if [[ "v3.0.35" == ]]; then echo "e5f2df8 on stable-3.0 is already tagged as v3.0.35"; exit 1; fi'
make: *** [tag] Error 2
```
Signed-off-by: Guillaume Abrioux <gabrioux@redhat.com>
Add a new "make tag" command. This automates some common operations:
1) Automatically determine the next Git tag version number to create.
For example:
"3.2.0beta1 -> "3.2.0beta2"
"3.2.0rc1 -> "3.2.0rc2"
"3.2.0" -> "3.2.1"
2) Create the Git tag, and print instructions for the user to push it to
GitHub.
3) Sanity check that HEAD is a stable-* branch or master (bail on
everything else).
4) Sanity check that HEAD is not already tagged.
Note, we will still need to tag manually once each time we change the
format, for example when moving from tagging "betas" to tagging "rcs",
or "rcs" to "stable point releases".
Signed-off-by: Ken Dreyer <kdreyer@redhat.com>
Co-authored-by: Guillaume Abrioux <gabrioux@redhat.com>
Prior to this change, if we created entirely new Git tags patterns like
"3.2.0alpha" or "3.2.0foobar", the Makefile would incorrectly translate
the Git tag name into a Name-Version-Release that would prevent upgrades
to "newer" versions.
This happened for example in
https://bugs.centos.org/view.php?id=14593, "Incorrect naming scheme for
a build of ceph-ansible prevents subsequent updates to be installed"
If we encounter a new Git tag format that we cannot parse,
pessimistically bail out early instead of trying to build an RPM.
The purpose of this safeguard is to prevent Jenkins from building RPMs
that cannot be easily upgraded.
With this change, "make srpm" will generate an RPM with "beta" in the
Release value.
For example, "v3.2.0beta1" will create
"ceph-ansible-3.2.0-0.beta1.1.el7.src.rpm"
It's not currently possible to install EPEL 7's fedpkg alongside the
centos-packager package in CentOS 7 Extras (for /usr/bin/cbs), because
they each depend on slightly different Koji package versions.
This means that we cannot run "make srpm" on a system where
centos-packager is installed, because that depends on fedpkg.
Remove the dependency on fedpkg for the "srpm" target, and run
rpmbuild -bs directly.
The purpose of this change is to make it easier to automatically
build ceph-ansible SRPMs in Jenkins/cbs.centos.org.
When "git describe" returns an "rc" tag (eg "2.2.0rc1"), insert the RC
number into the RPM's "Release" field.
Add comments with some git-describe values and NVRs.
Prior to this change, if we built an RPM from a tagged commit, the RPM
would have a release value of "0".
This causes some problems with RPM version comparisons when comparing
version numbers with "rc" tags/packages, which should also have a
less-than-one Release value.
Prior to this change, if there was a stray tag in the repository that
did not start with a "v", the Makefile would still try to use that tag
as a version tag when constructing the RPMs.
Only use the tags that start with "v", in this case.
Prior to this change, all RPMs would have a Version field that started
with "v", for example "ceph-ansible-v2.0.0-163.g2c98b1d.el7"
Strip the "v" out in these cases, so that the version is simply a
number.
"make rpm" will build a ceph-ansible RPM and place it in the current
working directory.
This will allow us to run this command in Jenkins for every branch.
Javier Pena
Ken Dreyer
Guillaume Abrioux