-
Notifications
You must be signed in to change notification settings - Fork 353
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add rules_swift 1.5.0 #327
Add rules_swift 1.5.0 #327
Conversation
277a3c7
to
47568b6
Compare
Yes, that's right. The "Publish to BCR" GitHub app should automatically create such a patch, but ideally you would bump the version before cutting the release. |
47568b6
to
99eb8a7
Compare
@meteorcloudy I restarted the build, but the CI gets stuck consistently after trying to apply the patches: https://buildkite.com/bazel/bcr-presubmit/builds/781#01853952-c258-4daf-854e-39f35df5ee4d |
Hmm, it looks like the patch command line tools is waiting for input, probably something is wrong with the patch content. But I'll check how to solve the hanging issue and give a better error message. |
99eb8a7
to
cd058e7
Compare
Fixing the hanging problem in bazelbuild/continuous-integration#1519 A manually run with
|
cd058e7
to
e29b3af
Compare
e29b3af
to
2d83334
Compare
The CI failure looks legit. I can reproduce it locally too, but there are no more details than this:
Building the target directly in the rules_swift repo works without bzlmod. The PR under question that changed that example project lately was this one, but I can't see anything that would break under bzlmod: bazelbuild/rules_swift#919 |
I can reproduce the failure by building from a module that depends on rules_swift 1.5.0 via a local_path_override. Couldn't get any meaningful error message. I wonder if this is hitting something similar to bazelbuild/bazel#16338 |
I ran the build with a version of Bazel that has a few
Not sure why the message never made it anywhere though. |
OK, sounds like bazelbuild/bazel#16338 is more important than we thought.. |
Since ec4be00, `AspectCreationException`s were no longer reported to the user, resulting in error messages such as: ``` ERROR: Analysis of target '//pkg:foo' failed; build aborted: ``` With this commit, the error looks like this instead: ``` ERROR: Evaluation of aspect //aspects:aspects.bzl%my_aspect on //pkg:foo failed: <causes...> ``` Context: bazelbuild/bazel-central-registry#327
I think it's actually an unrelated issue: a small regression introduced by bazelbuild/bazel@ec4be00, which is already in Bazel 5. I submitted a fix as bazelbuild/bazel#17071 |
Since ec4be00, `AspectCreationException`s were no longer reported to the user, resulting in error messages such as: ``` ERROR: Analysis of target '//pkg:foo' failed; build aborted: ``` With this commit, the error looks like this instead: ``` ERROR: Evaluation of aspect //aspects:aspects.bzl%my_aspect on //pkg:foo failed: <causes...> ``` Context: bazelbuild/bazel-central-registry#327
Thanks a lot for the investigation @fmeum! That was indeed the problem. I added a dep on |
This was discovered while registering the latest rules_swift release into the BCR and running the validation pipelines there. It was tricky to debug, but it seems like either a recent change in rules_swift or bzlmod and Bazel caused this to be required. bazelbuild/bazel-central-registry#327 Now that bzlmod is more stable, we should likely look into adding a bzlmod verification pipeline directly in this repo so we can catch regressions earlier.
Since ec4be00, `AspectCreationException`s are no longer reported to the user, resulting in error messages such as: ``` ERROR: Analysis of target '//pkg:foo' failed; build aborted: ``` With this commit, the error looks like this instead: ``` ERROR: Evaluation of aspect //aspects:aspects.bzl%my_aspect on //pkg:foo failed: <causes...> ``` Context: bazelbuild/bazel-central-registry#327 Closes #17071. PiperOrigin-RevId: 500883551 Change-Id: Iaf3b1dff8cb0915dd1ddc51d1d5e6578ff44029b
Since ec4be00, `AspectCreationException`s are no longer reported to the user, resulting in error messages such as: ``` ERROR: Analysis of target '//pkg:foo' failed; build aborted: ``` With this commit, the error looks like this instead: ``` ERROR: Evaluation of aspect //aspects:aspects.bzl%my_aspect on //pkg:foo failed: <causes...> ``` Context: bazelbuild/bazel-central-registry#327 Closes #17071. PiperOrigin-RevId: 500883551 Change-Id: Iaf3b1dff8cb0915dd1ddc51d1d5e6578ff44029b Co-authored-by: Fabian Meumertzheim <[email protected]>
Since ec4be00, `AspectCreationException`s are no longer reported to the user, resulting in error messages such as: ``` ERROR: Analysis of target '//pkg:foo' failed; build aborted: ``` With this commit, the error looks like this instead: ``` ERROR: Evaluation of aspect //aspects:aspects.bzl%my_aspect on //pkg:foo failed: <causes...> ``` Context: bazelbuild/bazel-central-registry#327 Closes #17071. PiperOrigin-RevId: 500883551 Change-Id: Iaf3b1dff8cb0915dd1ddc51d1d5e6578ff44029b
This was discovered while registering the latest rules_swift release into the BCR and running the validation pipelines there. It was tricky to debug, but it seems like either a recent change in rules_swift or bzlmod and Bazel caused this to be required. bazelbuild/bazel-central-registry#327 Now that bzlmod is more stable, we should likely look into adding a bzlmod verification pipeline directly in this repo so we can catch regressions earlier.
I think this will fail the verification of the zip having the same
MODULE.bazel
as the one that is checked-in, because the way the our release workflow works is that we first tag and build the release archive and only then we bump theMODULE.bazel
with an automated PR (such as bazelbuild/rules_apple#1793) after the release has been tagged already.I assume a patch changing the version number is the easiest way to fix this for now, and the recommendation is to change our workflow to bump the version number before we tag a release?