-
-
Notifications
You must be signed in to change notification settings - Fork 14.5k
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
consul: 0.9.3 -> 1.3.0 #48714
consul: 0.9.3 -> 1.3.0 #48714
Conversation
Signed-off-by: Vincent Demeester <[email protected]>
Please have a look at #44192 #41243 and #35602 and check questions raised before regarding
/cc @nh2 for review |
@GrahamcOfBorg build consul |
Failure on aarch64-linux (full log) Attempted: consul Partial log (click to expand)
|
Success on x86_64-linux (full log) Attempted: consul Partial log (click to expand)
|
Thanks! |
Oops, I missed that these questions should go to @vdemeester, not @c0bw3b. |
The UI actually breaks with this update. we either have to explicitly enable |
Some context: They switched to a |
Hmm, just tried out this PR's consul-1.3.0, but I'm a bit confused: The UI works for me as before, but doesn't look at all like the new UI on https://demo.consul.io/ui/dc1/services (which as per https://www.consul.io/intro/getting-started/ui.html is the default since 1.2.0), but instead looks like the old UI. That desipte I cannot find Why is that? |
We currently do not at all build the new UI. We need some extra patches for that. So (Guesswork here) maybe it fallbacks to the old UI if the new UI isn't found? In that case, we can just merge this as is, and add another patch later to add the new UI. |
@arianvp I don't understand that comment. Consul upstream docs say the new UI is built by default in 1.3.0, and |
@nh2 yes this is indeed the case. See https://github.com/hashicorp/consul/blob/25f04fbd21f6a8cc63385cba80092c8c8b1223b2/agent/config/flags.go#L106-L107 We enable So.. we can merge this as is, without breaking the UI. and we can later create a PR for adding the |
Ah, here is more info: Specifying We do that here:
Switching that to I've asked on the Consul gitter whether this behavoiur is intended, it doesn't seem to be documented. |
I think when we switch from |
@arianvp It doens't seem to need anything extra for me (see above): It works out of the box for me if I use - (if cfg.webUi then { ui_dir = "${cfg.package.ui}"; } else { }) //
+ (if cfg.webUi then { ui = true; } else { }) // |
That's... very surprising. as |
We found the solution. Apparently (and apparently starting with 1.2.0), for the purpose of bundling the UI into the binary, Consul started pre-building all UI stuff and putting it hex-encoded into hashicorp/consul@e875783#diff-a10b38c8ecb31208b7f65fa239f23226. They seem to generate that file with every release commit. This means we can throw away my README and all Ruby related UI building stuff, and we only keep |
Ok good! That would make the service module compatible with v1.3.0 with minimal changes. Also: the build failure on aarch64 seems to be just a thread number limitation on ofBorg ARM build server but if anyone can double check |
No, I made #49165 instead. We should close this. |
Closing in favor of #49165 😉 |
Removes the old UI build tooling; it is no longer necessary because as of 1.2.0 it's bundled into the server binary. It doesn't even need to have JS built, because it's bundled into the release commit's source tree (see NixOS#48714). The UI is enabled by default, so the NixOS service is updated to directly use `ui = webUi;` now. Fixes NixOS#48714. Fixes NixOS#44192. Fixes NixOS#41243. Fixes NixOS#35602. Signed-off-by: Niklas Hambüchen <[email protected]>
Signed-off-by: Vincent Demeester [email protected]
Motivation for this change
Bump consul to a more recent version
Things done
sandbox
innix.conf
on non-NixOS)nix-shell -p nox --run "nox-review wip"
./result/bin/
)nix path-info -S
before and after)