Rename the .build job to .build-linux and require the "docker" tag. Add
a corresponding .test-linux job and have the Linux test stages extend
it. Update various steps accordingly.
In the Windows merge request build job, don't pass
/consoleloggerparameters:PerformanceSummary;NoSummary to msbuild. It
makes the output more verbose and in turn makes errors more difficult to
find.
We have to use dedicated runners for Windows builds, so create a
separate "if-merged" rule for them which includes only the
wireshark/wireshark repository.
Build WiresharkPortable32 or WiresharkPortable64 as appropriate for our
target platform. Add WiresharkPortable64 steps to the Win64 builder.
Update the Developer's Guide. Fixes#17260.
GitLab CI annoyingly shows "⚙ blocked" in the pipeline UI if you have
any jobs that can be run manually instead of a green checkmark even if
all of the other jobs in the pipeline have passed. It's not clear that
"blocked" means "you can run this manually if needed," so adjust the
Documentation rule so that this doesn't happen.
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.
Gerald Combs