Byron / cargo-smart-release

Release complex cargo-workspaces automatically with changelog generation, used by `gitoxide`
Apache License 2.0
78 stars 7 forks source link

feat: improve error messages when path is not found in commit #13

Closed MingweiSamuel closed 9 months ago

MingweiSamuel commented 9 months ago

Alt

                    if let Some(released_dir_id) = released_target
                        .object()?
                        .peel_to_kind(object::Kind::Tree)?
                        .into_tree()
                        .peel_to_entry(components)?
                        .map(|entry| entry.object_id())
                    {
                        (released_dir_id != current_dir_id).then_some(PackageChangeKind::ChangedOrNew)
                    } else {
                        eprintln!(
                                    "path '{}' in released_target commit `{}` must exist as it was supposedly released there. Was it moved to a different directory? Changelog may have missing entries.",
                                    dir, released_target
                                );
                        Some(PackageChangeKind::ChangedOrNew)
                    }
MingweiSamuel commented 9 months ago

I guess moving a package completely obliterates the changelog, including the logs for old versions

MingweiSamuel commented 9 months ago

So yes I am interested in looking into that and have been reading through the source code. Wondering if a different strategy of looking at the workspace Cargo.toml file to see changed paths might simplify things

Byron commented 9 months ago

That's great to hear.

I must recommend though to prefer small PRs over sweeping ones, as this tool is totally under-tested. This means in order to know if it works for me, I have to try publish gitoxide, which is all it really has to do for me, and it has to keep doing that. Thus, testing by hand will be required to merge PRs which takes more time and is more dangerous, so I am more anxious about certain changes, which impedes contributions that change core logic.

Of course, the best way to deal with this would be to build out the test suite before making any changes, but it's something I skimped on for a reason before.

In any case, I hope the ramblings above help at least a little :).

MingweiSamuel commented 9 months ago

Is there a way to keep the old changelog? I see code for merging with the old. But when I run the bin it overwrites everything existing

Byron commented 9 months ago

It does keep the previous changelog, and the worst I have seen is that it doesn't understand anything and keeps the old changelog as a trailer. But maybe there are cases when that doesn't work.

The merge logic is quite complex, and probably also under-tested compared to the sheer amount of possible inputs, so I wouldn't be surprised if it can do what you describe.

MingweiSamuel commented 9 months ago

Ok, only the Commit Statistics and Commit Details are getting removed, it seems

Edit: seems they're not being parsed

Seems that it skips generated content. may be possible for me to manually modify the changelogs (so they get detected as user content) for my use case

Yup sweet, that works