Exclude unchanged crates from a release #298
Comments
|
Not a fan of the flag name but I wonder if we should actually make this the default behavior. If we make it a default or depending on how we expose this. one question is what to do with package selection flags. How should we handle the lock file? My guess is we should mark everything changed but let people know which ones were only because of the lock file. If we are making decisions on the users behalf, should we make the change detection more accurate? We can use |
We are now having `cargo` tell us which files are related to a package and which aren't. This is a step towards crate-ci#298. BREAKING CHANGE: We've removed the `exclude-paths` config field.
We are now having `cargo` tell us which files are related to a package and which aren't. This is a step towards crate-ci#298. BREAKING CHANGE: We've removed the `exclude-paths` config field.
|
I'm thinking we should at least make this advisory at first as we test out the logic. For example, a corner case I just thought of is we need to be checking if a dependency has changed since the current crate last released and not since the dependency changed since its last release. People can release individual crates for various reasons and we need to account for this. There are also a lot of dependency releases that don't impact their dependents. As we make this more automatic, we should probably be working to provide the user more information, like what the relevant commit summaries were. The challenge will be organizing all of the data to not overwhelm the user. |
This isn't to the quality to make decisions on behalf of the user, but
its a start. Remaining work
- Tracking changes-from-lock file
- Telling the user when a change is only because of the lock file
- Looking for changes in depenencies since the curren crates last
release, in case the dependency changed
- Except this will get annoying if the change doesn't matter because
it will keep bugging the user.
This is a step towards crate-ci#298.
|
Hmm, maybe we shouldn't consider changes from outside the current run. If someone decided not to make a release, it means they will keep having to make that decision each run. |
|
Lock files should only impact a crate if it has a |
`Cargo.lock` changes do not impact the release of a crate unless its a `[[bin]]` and someone is going to `cargo install` it. This is part of crate-ci#298.
|
A way we can narrow down transitive changes is if extract the change detection logic in This effectively means that a dependent will only be marked changed if we are doing a breaking change. Otherwise, newly generated lock files will pick up the change "for free". |
This is exactly why If this were to be implemented, the "familiarity by using the standard cargo arguments" reason vanishes from this tool. |
No. it doesn't |
Meaning of the flag changes with that. And that is what I meant by "familiarity by using the standard cargo arguments" being changed because the meaning of flags are not same anymore. Just the option name being same is not the familiarity I am talking about.
Feel free to look at how |
|
I just run Also because the dry-run tells you that the updated crate will be published: |
|
Was that first command all of the output? Could you run with a higher verbosity next time so we can have more context for what cargo-release is doing? You can do that by adding multiple |
Yes. I will try to reproduce this in my toy workspace at commit MarcoIeni/rust-workspace-example@10970de. Let's publish the first crateThere are three crates. None of them is published yet. Let's publish the first one: The crate is published and the tag is created. Perfect 👍 Let's publish the other two cratesI would like to release the other two crates by specifying the dry run: Even if we get an error (it shouldn't be an error in my opinion, because it is expected that some of the crates of the workspace might already be published), it seems that the other two crates are going to be published. Let's execute it: That's all 😢 |
|
Oh, that made it more obvious. I had missed that the tag existing messages were errors and its been a bit since I've been in this code. When in a dry-run, we continue through errors so you can see more details but we stop immediately when executing. Note that the dry run message is saying its trying to recover from a previous failure. We still do things like tagging in that case, so its proper that we check for it and error out because you've told us one thing (release all crates in a workspace) when doing so is suspect (tag already exists). Everything is working as expected with us not having this Issue implemented. You need to run Something we can improve is to change that last message to say to resolve the errors. |
Someone reported confusing behavior in a comment in crate-ci#298 that turned out to be because dry-run failed and we had both missed that. Now, if dry-run fails, we'll report a clearer message about it.
I see, but I was looking for a command I could always run in CI on main:
Is this something you want to support in |
|
Keep in mind, as of right now #117 is an issue for exploring automatically releasing in CI. I need to update it with some of my current thoughts / concerns. |
Maintainer's notes:
[[bin]]and the lock file changed=, major version changed)PR #296 adds a new flag,
--exclude-unchanged, that filters thepkgslist (after applying--package,--excludeetc.) to include only those packages that have changed since the last tagged release, plus their transitive dependencies. It uses the existing change-detection logic, and only marks a package "unchanged" if the code would have reached the existing"Updating {} to {} despite no changes made since tag {}"warning.The text was updated successfully, but these errors were encountered: