-
Notifications
You must be signed in to change notification settings - Fork 296
Revert "Merge pull request #386 ... gpb-recompilation...detection" #413
Conversation
Well this breaks the build. |
The build error is only for R16B and I'm not sure about the cause. Could it be a timeout in inttest/port_rt, and can we trigger a rebuild to see if that's it? |
It does indeed break the build. It fails for R16B only, in the port_rt inttest, testing compilation of C code. It seems to fail since the rebar compile process exits with exit code 130, which is 128+INT, after about 40 seconds of inttest execution (all inttests). There are other successful cases where the inttest has proceeded longer. It is unclear, due to lack of timestamps, how long this particular port_rt inttest has been running, but other timestamps in earlier inttests indicate it cannot have been more than 25 seconds, so it should have been safe from inttest's default timeout of 30s. I don't understand why, and I don't see how it could have happened as part of changing the recompilation strategy for protobuf files. Agree with @Tuncer about trying a rebuild. Is that anything I should do to trigger it? |
Not sure if there's a way to do it on travis-ci, but pushing a modified branch will definitely trigger a build. Maybe you can add a temporary debug log in that test and use that as the branch modification. |
e31fc2b
to
a7b7205
Compare
I added a debug-printout to port_rt.erl, and travis passed the tests. https://travis-ci.org/rebar/rebar/builds/44984703. So I did a reset to the previous commit, hoping this would trigger a travis-build with the branch in the shape I would want it to have, but github apparently remembered the previous travis build as well, hence it is still marked as failed. Oh so clever github :) |
I'll try closing and re-opening the PR, as per https://stackoverflow.com/questions/17606874/trigger-a-travis-ci-rebuild-without-pushing-a-commit |
Try again, GitHub was unavailable. |
Yeah that appears to work. I can defer to you and merge this whenever. |
Looks good to me. |
Can we land this in master? It's a prerequisite for the proper fix. |
Revert "Merge pull request #386 ... gpb-recompilation...detection"
This broke the build in master, but so did reversing the merge (in its own PR, see https://travis-ci.org/rebar/rebar/builds/45475087). Not sure what's to blame. I'm gonna try again later and see what happens. |
Tests have appeared to run fine locally at least. |
As per discussions with Tuncer Ayaz and Luis Rascão, partly in #410,
and partly as an off-github spinoff private discussion, this is a request to
revert the merge of #386, since it changed the gpb compiler to
not use
rebar_base_compiler
. That change was to add support fortarget name prefixes, but it is better to add that support to
rebar_base_compiler.