This will reduce unnecessary resource consumption by cancelling running workflows when new commits are pushed to a PR or workflow dispatch. It does not cancel pushes to main or branches.
Closes#16601
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/16601 from sethvargo:sethvargo/actions-concurrency 82fd070dba
PiperOrigin-RevId: 629805311
This will allow them to reuse our bazelrc and remote caching setup. This also silences the non-bzlmod windows test that's hitting the windows path length.
PiperOrigin-RevId: 626390416
We're seeing a high flake rate due to remote cache-misses only on Bazel 7 builds. The key change here seems to be adding the remote_download_output flag, but this also upgrades us to 7.1.1 and adds some retry behavior to caching issues.
PiperOrigin-RevId: 625892332
I'm not sure why exactly but GitHub Actions is complaining about the reference
to `matrix.PLATFORM`. Let's just delete that and the visionos builds until
we're ready to turn visionos back on.
PiperOrigin-RevId: 617922287
This installs a upb's static library, headers, and three protoc plugin binaries (upb, upbdefs, upb_minitable). These will now be enabled by default, but can be disabled by setting protobuf_BUILD_LIBUPB=OFF.
To qualify this, we hook into our existing install test infrastructure which attempts to build and run our tests without any of the installation artifacts available from the source tree. Public headers are deleted, and builds of exported libraries/binaries are disabled.
PiperOrigin-RevId: 617376961
The latest github runner image of ubuntu-22 includes a kernel update that breaks the sanitizers we use in our docker images. Long-term, we'll likely need to upgrade the images to new sanitizers and clang.
PiperOrigin-RevId: 616319042
The Bazel action currently isn't setup to regenerate the proto gencode itself, meaning that it won't actually be running on changes in the pending PR. Long-term, we should migrate this back to Bazel after enabling proto codegen properly.
PiperOrigin-RevId: 611238217
When we get a pull request from outside the protobuf repository, the tests will
not run until a protobuf team member adds the `safe for tests` tag. This change
updates the error message to make it more clear what has to happen to get the
tests to run.
Fixes#15847.
PiperOrigin-RevId: 608660908
This will enable us to get the correct crate names for Rust gencode. The actual
reading of the mapping file in protoc happens in the followup.
PiperOrigin-RevId: 597509582
This check enforces that each C++ build target has the correct dependencies for
all headers that it includes. We have many targets that were not correct with
respect to this check, so I fixed them up.
I also cleaned up the C++ targets related to the well-known types. I created a
cc_proto_library() target for each one and removed the :wkt_cc_protos target,
since this was necessary to satisfy the layering check. I deleted the
//src/google/protobuf:protobuf_nowkt target and deprecated :protobuf_nowkt,
because the distinction between the :protobuf and :protobuf_nowkt targets was
not really correct. Neither one exposed the headers for the well-known types in
a way that was valid with respect to the layering check, and the idea of
bundling all the well-known types together is not idiomatic in Bazel anyway.
This is a breaking change, because the //:protobuf target no longer bundles the
well-known types. From now on they should be accessed through the new
//:*_cc_proto aliases in our top-level package.
I renamed the :port_def target to :port, which simplifies things a bit by
matching our internal name.
The original motivation for this change was that to move utf8_range onto our CI
infrastructure, we needed to make its dependency rules_fuzzing compatible with
Bazel 6. The rules_fuzzing project builds with the layering check, and I found
that the process of upgrading it to Bazel 6 made it take a dependency on
protobuf, which caused it to break due to layering violations. I was able to
work around this, but it would still be nice to comply with the layering check
so that we don't have to worry about this kind of thing in the future.
PiperOrigin-RevId: 595516736
Latest bundler 2.5.0 release results in the following error: `The last version of bundler (>= 0) to support your Ruby & RubyGems was 2.4.22. Try installing it with gem install bundler -v 2.4.22 bundler requires Ruby version >= 3.0.0. The current ruby version is 2.7.3.183.`
PiperOrigin-RevId: 591288515
This makes third_party/utf8_range no longer a Git subtree, but instead the
permanent location and source of truth for utf8_range. It is also now
incorporated into the @com_google_protobuf Bazel repo. Utf8_range still has its
own separate CMake build for now, though.
PiperOrigin-RevId: 580682733
There's a test run in test_python.yml that is non-trivial to get working with
Python 3.12 due to some refactoring of our Docker images that would be needed.
But this change updates everything else to add coverage for Python 3.12.
The main changes necessary to get the builds working were to upgrade some Pip
packages via requirements.txt, including in a patch to `rules_fuzzing` that I
plan to upstream soon. I also had to take an explicit dependency on
`setuptools`.
I removed tox.ini, since it was outdated and we have not been actively
maintaining it.
PiperOrigin-RevId: 580548224
The initial job ran and found stale PRs/issues, but lacked the permission to comment on them, add labels, or close issues/PRs.
Any issues with 'help wanted' shouldn't be auto-closed as we want them to be able to sit inactive.
PiperOrigin-RevId: 580209299
We will soon be moving utf8_range into the protobuf repo, not as a subtree
anymore but as the real source of truth. This change adds CI coverage in
advance so that there will not be a lapse in coverage.
I also upgraded our pinned versions of rules_fuzzing and rules_python, to fix
some errors that came up with Bazel 6 and Python 3.12. I had to patch
rules_fuzzing but I am working on upstreaming the fixes.
PiperOrigin-RevId: 579987379