On MRs it uses the merge target as the reference.
In schedules it uses the latest released version for this branch as the
reference.
(cherry picked from commit 9a6e8b9190990c81dadbb5bb7e5bf1ed60aaad8c)
In specific circumstances the :iscman:`named` resolver process could
terminate unexpectedly when stale answers were enabled and the
``stale-answer-client-timeout 0`` configuration option was used.
This has been fixed.
Backport of !808
See isc-projects/bind9#5372
Merge branch 'backport-5372-security-serve-stale-crash-on-insist-unreachable-9.20' into 'v9.20.11-release'
See merge request isc-private/bind9!815
If ns__query_start() is called because of a chained query (e.g.
after encountering a CNAME), a previously set DNS_DBFIND_STALETIMEOUT
flag on the query's 'dboptions' field can cause an assertion
failure if the new query's 'stalefirst' value is not true (e.g. if the
target qname is an authoritative zone for the server). Reset the
DNS_DBFIND_STALETIMEOUT flag in the query_lookup() function before
evaluating the 'stalefirst' value, and make sure to assign a fresh
value to the `stalefirst' flag instead of conditionally assigning it
only if the value is 'true'.
(cherry picked from commit 3d8bd8bbf15322c0c317e76364b53ba7ea88def5)
When the interface-interval parser was changed from uint32 parser to
duration parser, the default value stayed at plain number `60` which
now means 60 seconds instead of 60 minutes. The documentation also
incorrectly states that the value is in minutes. That has been fixed.
Closes#5246
Backport of MR !10281
Merge branch 'backport-5246-fix-default-interface-interval-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!10679
When the interface-interval parser was changed from uint32 parser to
duration parser, the default value stayed at plain 60 which now means 60
seconds instead of 60 minutes. Fix the default value and the
documentation to match the reality.
(cherry picked from commit de08c0088dbdeac7e97c343835f4fdb465dff27d)
Root trust anchors are automatically updated as described in RFC5011.
Add a system test which ensures the root DNSKEYs are always queried by
named during startup.
Because this test uses real internet DNS root servers, it is enabled
only when `CI_ENABLE_LIVE_INTERNET_TESTS` is set.
Backport of MR !10615
Merge branch 'backport-colin/updaterootdnskey-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!10674
Root trust anchors are automatically updated as described in RFC5011.
Add a system test which ensures the root DNSKEYs are always queried by
named during startup.
Because this test uses real internet DNS root servers, it is enabled
only when `CI_ENABLE_LIVE_INTERNET_TESTS` is set.
(cherry picked from commit b0a33f77dce28d21036739c565cc0037ca605893)
Now, it is also run in schedules and most annoyingly on push which means
that it is run twice on a push to a branch where a MR exists and `.gitlab-ci.yml` is changed.
This was an oversight in https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/10654
Backport of MR !10668
Merge branch 'backport-stepan/remove-additional-pipeline-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!10669
Now, it is also run in schedules and most annoyingly on push which means
that it is run twice on a push to a branch where a MR exists.
(cherry picked from commit 7ca18df58a328690f788a474aefbb73e053616db)
- increase clarity of multiline messages
- support `isc.query.*()` query&response logging
- replace use of `print()` statement with proper logging
- omit empty lines from test result output
Backport of MR !10590
Merge branch 'backport-nicki/improve-pytest-logging-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!10660
The extra messages are typically traceback from assertion failures.
Previously, they'd be printed only after all individual test case
results have been printed. That made it difficult to pair the traceback
to the failing test in some cases, as the node information (aka test
name) might not always be present.
Instead, log any extra messages related to a particular test failure
directly after reporting its result, making the failure details more
readily available and easy to connect with a particular test case.
(cherry picked from commit fcf31417ddee33be028f69a1ea4326ccede46d78)
The command's stdout may provide useful debug info, so make sure we log
it by default. It doesn't seem to have a significant impact on the log
size.
(cherry picked from commit 9f3f6ec38e2ebb5314b1df72d0b28eb951a61038)
Make sure the queries and responses are logged at the DEBUG level, which
may provide useful information in case of failing tests.
This doesn't seem to significantly increase the overall artifacts size.
Previously, pytest.log.txt files from all system tests would take around
3 MB, with this change, it's around 8 MB).
(cherry picked from commit 56fec9ba04b3ddb82591d2c9edf4f073d650209c)
In some cases, it's useful to log the sent and received DNS messages.
Add options to enable this on demand. Query is only logged the first
time it's sent, since it doesn't change. If response logging is turned
on, then each response is logged, since it might be different every
time.
(cherry picked from commit 1e87b5ffc6c689942d37274659c78c382c1c6988)
When multiline message is logged, indent all but the first line (which
will be preceeded by the LOG_FORMAT). This improves the clarity of logs,
as it's immediately clear which lines are regular log output, and which
ones are multiline debug output.
Adjust the isctest.run.cmd() stdout/stderr logging to this new format.
(cherry picked from commit 23e6b49cc57cb41a0260686366e7ba86cac0ec4a)
The messages obtained from test results may contain stuff like detailed
failure/error information, tracebacks etc. In many cases, the message
will be empty, in which case it doesn't need to be logged.
For an example, run test with many test cases, e.g.
verify/test_verify.py, and inspect the tail of the pytest.log.txt before
and after this commit.
(cherry picked from commit 0a6b0cf68c6553f7eeef06fb507c1b28b9c61f38)
Use isctest.log logging facility for consistent and predictable logging
output rather than using print(). Remove writes of stderr, as that
output will be logged in the debug log in case the commands called with
isctest.run.cmd() fails.
(cherry picked from commit 4b8998e4ad1eda6e4fca23c362dd8034d6cce3fa)
If an new orphan anchor is (`.anchor: &anchor` with no corresponding `*anchor` elsewhere in the file) is introduced the CI job will.
Depends on https://gitlab.isc.org/isc-projects/bind9-qa/-/merge_requests/101 (merge that first and then drop the `--branch` commit).
Backport of MR !10654
Merge branch 'backport-stepan/ci-orphaned-anchors-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!10666
This test doesn't require artifact checking but when bundled in the same
directory with the shell based tests, the `system:clang:tsan` job was
failing non-deterministically.
(cherry picked from commit d5874d5df96259bda5c240fe785c97decdec1e23)
This is a test for #5380.
Backport of MR !10596
Merge branch 'backport-stepan/mirror-root-zone-from-the-internet-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!10657
We skip those by default as:
a) we don't want to stress the upstream servers in every CI pipeline
b) system tests need to be runnable in a isolated environment by default
(cherry picked from commit 3a8ffc74df5f097afa9cd2b7073dc732824e82dd)
Previously, JUnit files were not generated or were generated empty for various reasons for some system/unit test runs.
Now, the number of tests collected for a MR is up from about 4k to 5.8k in the "Tests" tab of a pipeline.
Additionally, there is a check that ensures that [a somewhat sane](c5a271eb8b) `junit.xml` file is generated after every system/unit test job and fails the job otherwise.
Closes#5316
Backport of MR !10556
Merge branch 'backport-5316-ensure-junit-xml-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!10649
There might be more than one :test-result: and they are collated into
the :global-test-result: field.
This only happens when system tests are run with `make check`.
In some cases the report wasn't generated, sometimes it wasn't kept
properly. This unifies the way artifacts are generated and kept.
(cherry picked from commit 4ec1a37ca090df41f046e20c6a6c788e7a4a0afe)
In the past artifacts of different types of system test jobs were
treated differently but this is no longer the case.
(cherry picked from commit c61ff639b3a5aa7d4513efdc893aadff95a56c60)
In the tumbleweed image, we utilize LibreSSL. Several BIND 9 libraries
are linked against LibreSSL's libcrypto.so.55, and when Kerberos is
enabled, we link against libk5crypto.so.3, which in turn links against
OpenSSL's libcrypto.so.3. This might theoretically lead to a symbol
conflict.
Closes#5394
Backport of MR !10643
Merge branch 'backport-5394-disable-kerberos-in-tumbleweed-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!10651
In the tumbleweed image, we utilize LibreSSL. Several BIND 9 libraries
are linked against LibreSSL's libcrypto.so.55, and when Kerberos is
enabled, we link against libk5crypto.so.3, which in turn links against
OpenSSL's libcrypto.so.3. This might theoretically lead to a symbol
conflict.
(cherry picked from commit 1b2c191bed4097e1095de3bc2f3854b6db894a8e)
The prep_doc_mr.py script of the bind9-qa repo needs a way to know that
gitchangelog.py did not produce entries. In the case of release notes,
it dies with "No commits matching given revlist". For changelog entries
it used to warn about "Empty changelog", but did not return non-zero
exit code.
Backport of MR !10591
Merge branch 'backport-mnowak/make-empty-changelog-fatal-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!10641
The prep_doc_mr.py script of the bind9-qa repo needs a way to know that
gitchangelog.py did not produce entries. In the case of release notes,
it dies with "No commits matching given revlist". For changelog entries
it used to warn about "Empty changelog", but did not return non-zero
exit code.
(cherry picked from commit 4d0ae4068f07a0f1a62b11629d3f26d798bddb45)
Previous CPU test relied on either missing default named.conf or the
missing permissions to write into its default directory. In short that
default configuration would be unusable with current user. It would hang
indefinitely at cpu test if the named user could write into directory
specified in default configuration.
Change it instead to explicitly try non-existent configuration file.
It will still fail immediately, but will not rely on running user or
presence of file at default configuration file path.
(cherry picked from commit 8e789ea62f882cc3f1308de16dd3ca22ef0f8f04)
