-
Notifications
You must be signed in to change notification settings - Fork 23
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
fix(holesky/docker): add environment variable replacement in entrypoint #371
Conversation
bolt-sidecar/bin/sidecar.rs
Outdated
fn init_tracing() -> eyre::Result<()> { | ||
let std_layer = FmtLayer::default().with_writer(std::io::stdout).with_filter( | ||
EnvFilter::builder() | ||
.with_default_directive("bolt_sidecar=info".parse()?) | ||
.from_env_lossy() | ||
.add_directive("reqwest=error".parse()?) | ||
.add_directive("alloy_transport_http=error".parse()?), | ||
); | ||
Registry::default().with(std_layer).try_init()?; | ||
Ok(()) | ||
} |
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.
Can you explain why you moved this function here?
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.
Imo it was weird that tracing was initialised in a function called init_telemetry_stack
, I didn't expect to find it there. What do you think?
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.
I would keep it in telemetry as we use it as a container for "all things monitoring"
@@ -4,23 +4,17 @@ services: | |||
container_name: bolt-sidecar-holesky | |||
restart: unless-stopped | |||
ports: | |||
- "${BOLT_SIDECAR_PORT:-8017}:${BOLT_SIDECAR_PORT:-8017}" # Bolt RPC port (this should be opened on your firewall!) | |||
# NOTE: to read these envs, it is necessary to provide them via `--env-file` or having them already set. |
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.
What does this mean? You removed env_file: ./bolt-sidecar.env
and now we need to pass it as a flag when running docker compose up?
If so, why? I don't get what the problem was with leaving the env file there
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.
Note: it is already like this -- the full command to spin up the docker compose for Holesky is
docker compose --env-file bolt-sidecar.env up -d
See https://github.com/chainbound/bolt/blob/lore%2Ffeat%2Fholesky-launch/testnets/holesky/README.md#L477-L477 (btw docker compose up -d --env-file bolt-sidecar.env
is wrong, the argument should be placed before, I'm going to fix that).
That flag is needed because, unless you've them already set, these envs cannot be read in the docker compose file. Lastly, invoking docker compose with the --env-file
and then providing the env_file
property in the docker compose with the same file is completely redundant.
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.
Makes sense, ty!
Some more thoughts on this: I don't like the added complexity of this solution vs the benefits that it brings. Wouldn't it be possible to just mark optional variables with "OPTIONAL: default true" or "OPTIONAL: default none"? example: # URL of the EL node to connect to
# REQUIRED, default: http://localhost:8545
BOLT_SIDECAR_EXECUTION_API_URL="http://localhost:8545"
# If using delegations, this variable must be provided and point to the file
# containing signed delegation messages.
# OPTIONAL, default: none
# BOLT_SIDECAR_DELEGATIONS_FILE=delegations.json |
We actually do it for two reasons:
All of this is done improve UX on the user side: just write down your preferences in the |
Thanks for the detailed explanation, sounds good! |
Couple things:
environment
section or via--env-file
flag they are system-wide inside the container and therefore removing them within the sidecar process doesn't work, because you can't remove a system-wide environment variable viaenv::remove_var
..env
file is not provided