Specify arbitrary container arguments #1315
Conversation
to container runtimes using a new configuration key under `build.env`. This gives users the flexibility to work around issues such as cross-rs#1012 without having to wait for a new release or creating their own forks of `cross`.
implemented in the configuration file and parsed from environment variables.
by adding an empty default value for `extra_args` where required.
har7an
force-pushed
the
feature/arbitrary-container-arguments
branch
from
f51b2c4 to
1034191
Compare
There was a problem hiding this comment.
How is this different from CROSS_CONTAINER_OPTS defined here https://github.com/cross-rs/cross/blob/37c681a923407b67044ea09c40205012c0ea86d5/src/docker/shared.rs#L1057C45-L1057C45?
obviously this adds a way to specify it in the config file, but other than that I don't see any difference.
If it is the same, I'd prefer removing CROSS_EXTRA_ARGS and making CROSS_CONTAINER_OPTS available in config file.
I guess it isn't at all, but the cross README (which is the usual entrypoint for people new to a project) has a section Configuration, which lists three options, two of which link here. Neither of the "highlighted" config options talks about configuration through environment, nor does the Finding the docs about environment variables seems to be mostly a matter of coincidence (unless of course I missed something obvious in which case I'm sorry) and now that I found it, it seems to me that this page also supersedes the So it seems this is mostly a matter of documentation. I'll happily update the docs if that's alright for you. About exposing the env variable settings through the config file: Should I keep the code snippet you listed and add the file-based config alongside it, or would you prefer if I updated the code in my PR to read |
|
Alright! Thank you for identifying the cause of the problem. We link to the wiki in the README under #usage, but this can definitely be improved. I think we could make the situation you've identified better by
as for the question about config, I'm not entirely sure what I'd prefer myself. There's some alternatives available as I see it
|
|
Hi @Emilgardis, sorry for taking so long but I recently "rediscovered" my previous progress on the matter on my PC and decided to invest some more time into it. I opened a new PR #1438 that deals with the documentation "issue". I'm fine with leaving the code as is and having only the env var to set additional arguments for the container runtime. This perfectly suits my needs. I'll leave the PR open for now pending a reaction in #1438. If you feel its' no longer needed you can close it as well, of course. |
Sort of a follow-up to #1315 which revealed a "mismatch" between what the `README` and `docs/` folder immediately provide as info compared to what's actually available. This restructures the `docs/` folder and adds information from various sources to it: - The README, - The Wiki - Examples found in the Wiki At the moment this duplicates a decent amount of information already available on the Wiki. Strictly speaking this was already the case before this MR, where the `README` and `cross_toml` each contained information from the Wiki. My motivation for moving these things into the `docs/` folder is that: 1. I'm much more used to finding information in a `docs` folder than to check for the Wiki. Most projects just don't use the Wiki 2. I usually expect the documentation to be part of what I check out, and the Wiki is *not* a part of this repo, but its own repo 3. Docs can be updated *as part of the same PR* that updates the respective code, and arbitrary checkouts of the repo will always contain the docs *valid for that version* On a personal note, I much prefer editing text in an editor I'm comfortable with, and Browsers don't fall into that category. I'm curious to hear your thoughts on this proposed change.
Implements the ability to pass arbitrary arguments to the underlying container runtime (
podman/docker). This functionality is currently exposed:build.env.extra_argsEXTRA_ARGSand takes a vector of strings. These strings are then injected into the container commandline.
This allows solving problems such as #1012 without having to wait for a new release of
crossto handle every users needs.The PR currently lacks tests and documentation. I wanted to put this up here to discuss the idea first before investing more time into it.