Running "make install" in a separate job in the "test" phase of a CI
pipeline causes a lot of object files to be rebuilt due to the way
artifacts are passed between GitLab CI jobs (object files extracted from
the artifacts archive have older modification times than their
respective source files checked out using Git by the worker running the
"install" job). Test "make install" in one of the build jobs instead,
in order to prevent object rebuilding.
Using 'after_script' for this purpose was not an option because its
failures are ignored.
Duplicating the build script in two places would be error-prone in the
long run and thus was rejected as a solution. YAML anchors would also
not help in this case.
A "positive" test (`test -n "${RUN_MAKE_INSTALL}" && make install`)
would not work because:
- it would cause the build script to fail for any job not supposed to
run "make install",
- appending `|| :` to the shell pipeline would prevent "make install"
errors from causing a job failure.
Due to the above, a "negative" test is performed, so that:
- jobs not supposed to run "make install" succeed immediately,
- jobs supposed to run "make install" only succeed when "make install"
succeeds.
In an attempt to ensure that:
- all important changes to repository contents are tested,
- pipelines are not automatically created for every single push,
- some flexibility is allowed for corner cases,
change pipeline triggering settings so that:
- full build & test pipelines are only automatically created for merge
requests and tags (both for creation and updates),
- pipelines for other repository changes (e.g. pushes to arbitrary
branches) can only be created manually, using GitLab's web
interface,
- merging a merge request only causes jobs pushing the updated ARM to
GitLab Pages to be run (as semi-linear Git history is enforced and
thus testing a MR is identical to testing the target branch
post-merge in terms of code),
- repository synchronization does not trigger duplicate pipelines in
projects which are set as mirroring targets.
Make sure all jobs are named using the following pattern:
[<job-type>:]<build-type>:<system>:<architecture>
where specifying <job-type> is optional for "precheck" and "build" jobs.
This should make it easier to quickly recognize:
- what kind of actions are performed by each job,
- which BIND build flavor is used by each job,
- which operating system image is used by each job.
There is no need to build BIND binaries before building docs and thus
the job building the current version of the ARM can be moved to the
build stage of CI.
Remove the following from .gitlab-ci.yml:
- unused variable definitions,
- unused Docker image definitions,
- commands which have no effect,
- sections which were commented out.
Whenever master or one for the v9_* branches gets updated, the current
ARM should be published on GitLab Pages. Add a pipeline stage which
takes care of triggering GitLab Pages pipelines. Extend the lifetime of
artifact archives containing the ARM to prevent GitLab Pages pipelines
from failing due to artifacts being unavailable.
Add a CI job which generates the HTML version of the ARM and makes it
available for download. Since this is expected to be a quick process,
the new job is enabled for all pipelines.
Modify .gitlab-ci.yml so that every CI pipeline also builds and tests
BIND on CentOS versions 6 and 7. Use --disable-warn-error on CentOS 6
since it uses GCC 4.4.7 which suffers from bugs causing bogus warnings
to be generated, e.g.:
sigs_test.c: In function 'compare_tuples':
sigs_test.c:75: warning: declaration of 'index' shadows a global declaration
/usr/include/string.h:489: warning: shadowed declaration is here
sigs_test.c: In function 'updatesigs_test':
sigs_test.c:193: warning: declaration of 'index' shadows a global declaration
/usr/include/string.h:489: warning: shadowed declaration is here
The Docker images used for CI install ATF to /usr, not /usr/local.
Update the ./configure invocation in .gitlab-ci.yml accordingly in order
to prevent confusion.
