-
Notifications
You must be signed in to change notification settings - Fork 305
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_erlang 3.2.0 #101
Conversation
5e6882d
to
b2a2376
Compare
@meteorcloudy the change of
The |
/cc @Wyverald |
You probably ran into a breakage at Bazel@HEAD that causes toolchain resolution errors. I'm debugging it as we speak -- hopefully have something to share in the next hour. If not, I'll look at rolling back the change. Sorry for the inconvenience! |
Fix out at bazelbuild/bazel#15666 |
b2a2376
to
3333f86
Compare
Thanks @Wyverald . How do I know when the fix has propagated sufficiently to retest? You changes appear merged, but the error persists after I rebased this branch to re-trigger the checks. |
Sorry, this turned out to be much more involved. My fix only addressed a subset of the breakage. The full fix would require bazelbuild/bazel#14852 to be fixed, which will probably take another week or so. So I'm going to roll back the partial fixes to the previous delicate balance we had (which happened to work) for now. Will keep you updated here. |
The rollback has been submitted (bazelbuild/bazel@4ccc21f), but the postsubmit pipeline hasn't caught up due to a flaky test, so "last_green" doesn't include this change yet. You can follow the BuildKite page for the pipeline progress. |
Thanks for the updates @Wyverald |
1bd8866
to
2219945
Compare
There seem to have been several green commits in the above pipeline, but the same error in the checks. What would I be looking for to determine the rollback on bazel has propagated sufficiently? |
@Wyverald I've rebased this a couple of time and the checks still seem to fail. I wonder if I am running into a more complicated issue than originally thought. These checks passed when the I am wondering if I ought to remove the register_toolchains(
":erlang_toolchain_external",
) from the |
f51dd07
to
5df4b9f
Compare
w.r.t toolchains -- the Beyond that, yes apparently some things are still broken :( I'm still trying to debug what changed. Sorry about the breakage! |
5df4b9f
to
d4b7c59
Compare
4b46351
to
79f75d1
Compare
79f75d1
to
12750c8
Compare
@Wyverald this is still failing even after a recent rebase. It looks like toolchain resolution still has issues in certain cases? I recall when the |
it looks like you simply don't have any toolchains registered. Could you try adding the line |
@@ -24,3 +24,7 @@ use_repo( | |||
"getopt_src", | |||
"xref_runner_src", | |||
) | |||
|
|||
register_toolchains( | |||
":erlang_toolchain_external", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry for the churn -- you need to write "//:erlang_toolchain_external" here (with the //)
When you wrote Now your 3.2.0 version is passing (well, will be passing once we fix the toolchain label, I think), but the 3.1.0 version will stay erroneous unless you also fix the MODULE.bazel file. But even that might not be great -- ideally you'd fix the MODULE.bazel file upstream, instead of just in the BCR. |
b3d18cb
to
bbfa62e
Compare
Independently I'm confident |
That does not seem to be sufficient, adding |
Do you mean that adding |
I added it to the Edit: |
Calling register_toolchains in WORKSPACE only registers it when you're building from within rules_erlang. If you're a Bazel module that has a If it's working for all your projects, it has to be because your projects are registering the toolchain themselves too somewhere. |
Ah, you're right. In some cases we are using the older |
As I recall we do not want unconditional registration for modules depending on rules_erlang
I remembered that we do not register this particular toolchain unconditionally, so it's purposefully only declared in the WORKSPACE. Then it finally sunk in regarding the way modules are tested as you described above. So, I added the toolchain registration to the |
After a little more trial and error, I realized that previous checks must have relied on some undocumented behavior of the test infrastructure. The |
https://github.com/rabbitmq/rules_erlang/releases/tag/3.2.0