Move common fuzzing configuration items to .fuzz-ubuntu. Build using
Clang, which is what the Buildbot fuzzers did. Add jobs for fuzzing
using Valgrind and randpkt.
This reverts commit b258f90ce5, which was
an attempt to fix a CI build issue by changing our Qt version. That
didn't fix the issue. Switching from CMake 3.20 to 3.19.8 *did*, which
suggests that we've run into
https://gitlab.kitware.com/cmake/cmake/-/issues/21145
Add a -t option to tools/fuzz-test.sh which lets you specify a maximum
fuzz time.
Add an initial "fuzz-test" job which fuzzes test/captures/* for 5
minutes. To do: Fuzz longer using our capture menagerie and report
failures.
Rename the "docbook" job to "documentation". Make sure we can do syntax
highlighting and produce PDFs. Distribute the docs that we build. Allow
the job to be manually run if we don't update any documentation sources.
Build the wsar_html_zip instead of wsar_html and (re-)publish it at
https://www.wireshark.org/download/docs/. Move the doxygen_all job to
the daily schedule section.
The files we need to submit to Coverity might be too large to upload
over HTTP, so use their URL submission method. We won't have a usable
artifact URL until after each cov-build job runs, so we need to submit
our URLs in separate jobs.
There are three ways to reuse configuration blobs in .gitlab-ci.yml: The
"extends" keyword, YAML anchors, and "!reference" tags. As noted in
https://gitlab.com/gitlab-org/gitlab/-/issues/322992, only the last
method works for job rules. Clean up our common rules and apply them
using "!reference".
It looks like "extends" and YAML anchors don't work for scheduling
rules, at least for the way we're using them. Use explicit rules for
scheduled jobs.
Move commonly-used rules to their own hidden jobs. Use ".if-merged" to
ensure that our production build and test jobs are run automatically in
wireshark/wireshark and can be run manually in forks.
Note the new manual behavior in the Developer's Guide.
Trying to upload cov-build output on Windows is currently failing
because the file is too large. Expose the build file as an artifact and
submit its URL instead.
Switch the recent analysis builds from only/when to rules.
Switch the API reference and VS Code Analysis builds to daily.
Remove a no-longer-useful URL.
The test:rpm-fedora job is currently failing with:
$ dnf install -y build/packaging/rpm/RPMS/x86_64/*.rpm
Fedora 34 openh264 (From Cisco) - x86_64 6.4 kB/s | 2.5 kB 00:00
Fedora Modular 34 - x86_64 8.4 MB/s | 3.8 MB 00:00
Fedora Modular 34 - x86_64 - Updates 500 kB/s | 754 kB 00:01
Fedora 34 - x86_64 - Updates 11 MB/s | 5.8 MB 00:00
Fedora 34 - x86_64 21 MB/s | 57 MB 00:02
Error:
Problem: conflicting requests
- nothing provides libminizip.so.2.5()(64bit) needed by wireshark-qt-3.5.0rc0_1661_ge2e4b79d0dd3-1.x86_64
It looks like this is due to Fedora 34 and later shipping with
minizip-3.0: https://src.fedoraproject.org/rpms/minizip.
Disable the test:rpm-fedora job for now until we can find a way to make
it more reliable.
As described at
https://medium.com/@alasher/colored-c-compiler-output-with-ninja-clang-gcc-10bfe7f2b949
both Clang and gcc generate colorized output when they detect a
terminal, but not for piped output, which is the case when using Ninja.
Add an ENABLE_COMPILER_COLOR_DIAGNOSTICS CMake option, and set it to
"ON" when we're using Ninja.
In the merge-req:ubuntu-gcc-ctest and merge-req:ubuntu-clang-other-tests
GitLab CI jobs, generate colorized HTML report artifacts using
ansi2html.
The Windows MR builder was recently migrated to a new machine and
updated to Qt 5.15.2. Since the migration merge request builds have
sometimes failed with
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(240,5): error MSB8066: Custom build for 'C:\builds\wireshark\wireshark\build\CMakeFiles\7345cb0fc1b52560d4d2bd48e83ff433\wireshark_de.qm.rule;C:\builds\wireshark\wireshark\build\CMakeFiles\7345cb0fc1b52560d4d2bd48e83ff433\wireshark_en.qm.rule;C:\builds\wireshark\wireshark\build\CMakeFiles\7345cb0fc1b52560d4d2bd48e83ff433\wireshark_es.qm.rule;C:\builds\wireshark\wireshark\build\CMakeFiles\7345cb0fc1b52560d4d2bd48e83ff433\wireshark_fr.qm.rule;C:\builds\wireshark\wireshark\build\CMakeFiles\7345cb0fc1b52560d4d2bd48e83ff433\wireshark_it.qm.rule;C:\builds\wireshark\wireshark\build\CMakeFiles\7345cb0fc1b52560d4d2bd48e83ff433\wireshark_ja_JP.qm.rule;C:\builds\wireshark\wireshark\build\CMakeFiles\7345cb0fc1b52560d4d2bd48e83ff433\wireshark_pl.qm.rule;C:\builds\wireshark\wireshark\build\CMakeFiles\7345cb0fc1b52560d4d2bd48e83ff433\wireshark_ru.qm.rule;C:\builds\wireshark\wireshark\build\CMakeFiles\7345cb0fc1b52560d4d2bd48e83ff433\wireshark_sv.qm.rule;C:\builds\wireshark\wireshark\build\CMakeFiles\7345cb0fc1b52560d4d2bd48e83ff433\wireshark_uk.qm.rule;C:\builds\wireshark\wireshark\build\CMakeFiles\7345cb0fc1b52560d4d2bd48e83ff433\wireshark_zh_CN.qm.rule;C:\builds\wireshark\wireshark\build\CMakeFiles\9829b32238fa3bcc807b02099e4c1642\qtui_autogen.rule' exited with code -1073740940. [C:\builds\wireshark\wireshark\build\ui\qt\qtui_autogen.vcxproj]
Try switching back to Qt 5.15.1. If that doesn't work we might have to
un-migrate the runner.
Fetching the complete Wireshark repository in GitLab's CI currently
takes about 3.5 minutes. GitLab CI lets you do shallow cloning, but only
up to 1000 commits. This isn't sufficient for any of our jobs that might
need a reachable tag since it's currently about 1200 commits away in
master.
Set GIT_DEPTH to 1 (which appears to trigger the required shallow clone
logic in GitLab's CI), then deepen it by setting GIT_FETCH_EXTRA_FLAGS
to "--depth=5000". This is *should* be much faster than a full checkout
and still give us a reachable tag:
$ git rev-list --count v3.3.0rc0..v3.5.0rc0
2330
$ git rev-list --count v3.1.0rc0..v3.3.0rc0
2198
$ git rev-list --count v2.9.0rc0..v3.1.0rc0
3449
Overriding the definition of the rpmbuild macro cmake_build on the
command line, so that it doesn't include the string "--verbose", should
prevent cmake --build from being run with --verbose, and thus prevent it
from running Ninja with the -v flag, and thus prevent a bunch of extra
noisy output from being produced for every build command, and thus
prevent the build log from hitting GitLab's 4MB limit.
Unlike piping the output of "ninja rpm-package" to sed, this means that
the exit status of "ninja rpm-package", rather than the exit status of
sed, is tested.