it’s not so simple unfortunately. it would still likely take much longer than a single PR. especially if someone else merges a change in the meantime. then still a lot needs to be rebuilt. and the most expensive parts are the tests which would most likely trigger for both cases.
it’s not that it would be hard to change this or that it would disrupt developer’s workflows so much. i just doubt it would be valuable enough. i think it would be worse than what we have now because it’s non-enforceable. devs can do “chore” style commits that do not modify deployments. they can modify their PRs throughout its lifecycle so that deployments target change to what they initially put. it’s not about developers not knowing what they’re changing, it’s about the UX of putting this information into their change. it’s easy to make a mistake in this workflow. if we had 99% accuracy per commit in this workflow (which i think it’s already extremely high), for a release with 50 commits, there’s only a 60% chance that we get accurate release notes.
i’m confident that the current approach we’re trying to implement will result in highly accurate release notes. we can reliably detect if a commit changed the guestOS build (with target-determinator as opposed to what we’re doing now which has some drawbacks), and then we’ll able to label some known packages as not relevant to guestOS changes. finally, we’ll make all the commits available in the release notes in one way or the other so that they can all be reviewed. i think labeling might still be not as accurate as we’d want at times (i.e. if a change is relevant or not), but we’ll 100% know which commits indeed modify the guestos deployment.
i think if we still do not get good results from this, we can try your suggestion and see if we can get some improvements with it.