* Helper flags for swift compilation
* Documentation for swift project integration
* Adds swift to the languages with coverage
* Only thread sanitizer is supported
* Fixes swift coverage target compilation
* fixup flags facotring
* swift: run on new ubuntu
* fixup
* swift: right copy for symbolizer
Important functional changes involve mostly improvements to
the command line scripts (this doesn't affect the build infra, only
local use):
1. Make sure scripts use the same builder as builds requested by infra, otherwise builds
will be very slow and will fail for larger projects.
2. Allow users to specify --test-images to use base images with suffix "-testing"
3. Allow script users to specify --parallel for parallel builds.
4. Allow script users to specify --testing so that builds are uploaded to testing buckets.
5. Allow script users to specify --branch so that builds use specified branch instead of master.
6. Clone oss-fuzz with depth 1 for improved speed and space usage.
7. Use logging instead of writing to stderr or print.
8. Allow scripts to accept multiple projects.
9. Allow script to keep executing after failure to get build steps.
10. Change scripts to use python3.
11. Tag more so builds are easier to query.
12. Log the gcb page for each build.
Other changes include major refactoring:
1. Don't construct image names from scratch using format strings each time they are used.
Provide a helper function for this.
2. Provide a helper function, get_env instead of constructing the env from scratch each time.
3. Move compile step into its own function: get_compile_step.
4. Move upload steps into their own helper function get_upload_steps.
5. Don't misuse the name image_project when we really mean cloud project.
6. Move cleanup step into its own helper function: get_cleanup_step.
7. Exit with returncode of main function from build_project.
8. Add unittests for build_project.
9. Make request_build share run_build code with build_project.
10. Use proper spacing in comments.
11. Test builds other than libfuzzer-ASAN-x86_64. Test other sanitizers, fuzzers and architectures
12. Make build_and_run_coverage share more code with build_project.
13. Move tests for build_and_run_coverage_test.py out of requst_coverage_test.py into their own file.
14. Use single quotes for strings.
15. Store state for a build in Build object instead of passing it everywhere.
16. Don't abuse project_yaml dict for storing project state. Use a Project object instead.
17. Better variable naming.
18. Use more classes instead of passing around arguments.
19. Use more f-strings.
20. Make scripts share main function.
21. Begin comments with uppercase and end with period.
22. Don't import functions or classes as dictated by style guide.
23. Share more test code in test_utils
Related: #6180.
This is done in anticipation of the upgrade to Ubuntu 20.04 which wont support this.
We'll do this first so we can handle any breakages caused by this step before needing to handle breakages
caused by the upgrade. However, there shouldn't be any breakages due to #6281, but there may be some projects
we overlooked.
The only exception to this is libcxx.
Related: #6180.
Removes unnecessary stuff in base-builder image to create a base-builder-new, and then adds a base-builder-swift on top of this that swift projects can use (without JVM/Go/etc fuzzing).
[infra][build] Set HOME=/root on GCB when doing fuzzer builds.
GCB passes HOME as env var to the docker container. It sets
HOME to /builder/home which is persisted accross builds.
This issue causes build breakages in
https://github.com/google/oss-fuzz/issues/6035
and possibly https://github.com/google/oss-fuzz/issues/5317.
Perhaps more insidiuosly it can cause fuzzers to be built with
the wrong instrumentation.
* [build/infra] Build engines in alphabetical order.
Previously, a project fuzz targets were usually built in the order:
libfuzzer, afl, honggfuzz. This can bias results if one is looking
at which engine finds bugs first.
* fix tests
* lnt
Generate badges also for projects with no coverage builds at all (e.g.
JVM and Python projects). For these projects, the badge only has the two
possible states "build passing" and "build failing".