-
-
Notifications
You must be signed in to change notification settings - Fork 96
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
Proposed design for including extra files in the archive #1340
Comments
Thanks for the proposal! I think at the time I wrote that comment in #423, our config system wasn't fleshed out to the degree that it is today. I completely agree that the right place to stick this is in configuration. I think the way I'd do this is something like: [profile.ci]
archive-include = [
{ path = "foo", relative-to = "target" },
{ path = "bar/*", relative-to = "target-profile" },
]
I'm enthusiastic about you (or someone else) doing it, so thanks again! |
Note that in cross-compilation scenarios, |
I think your design makes sense since it seems more extensible and keeps all the include config in a single root level entry. I'm not sure what you mean by "small parser that replaces recognized names with the corresponding paths at runtime.". |
Sorry, that bit was left over from an earlier iteration of the comment I was typing -- ignore it. |
@rukai: finally got some time to finish this up! Will release tomorrow during working hours Pacific time. |
Ah sadly I couldn't get it done today, was busy at work and also realized that we needed to make some fixups. All good to go tomorrow though. |
Just released cargo-nextest 0.9.69, binaries will be out in 15-20 minutes. |
Ah, hmmm, ran into a build issue: https://github.com/nextest-rs/nextest/actions/runs/8823439041/job/24223903333 |
OK, out in cargo-nextest 0.9.70. Yay! |
Maintainer edit, tracking TODOs:
From reading the discussion in #423 it sounds like a feature like this is welcome.
But I wanted to make a proposal for a design before I set about implementing it.
I propose that we add the following configuration options to the config file and they will behave as documented.
I believe that these 2 config options should cover all possible use cases.
Alternatively we could have a single config option and support
*
globbing for profile specific paths. e.g.*/application-data
But that would mean that both release and debug builds would be included.
This design intentionally does not intend to add CLI flags for this as it feels like a build configuration level problem and not something the user would want ad-hoc control over.
But @sunshowers did mention including CLI flags for it in #423 , so maybe there is a motivation I'm missing.
The text was updated successfully, but these errors were encountered: