Only create distinct changesets #2019
Conversation
blast-hardcheese
force-pushed
the
only-create-distinct-changesets
branch
from
7cf89ac
to
39d3211
Compare
Codecov Report
@@ Coverage Diff @@
## master #2019 +/- ##
==========================================
+ Coverage 78.58% 78.74% +0.15%
==========================================
Files 131 132 +1
Lines 2251 2272 +21
Branches 54 47 -7
==========================================
+ Hits 1769 1789 +20
- Misses 482 483 +1
Continue to review full report at Codecov.
|
|
Codacy failed because I used |
|
😅 Gonna think about this one more. If there is something obvious about the project structure I'm missing, I'm all ears, but I'll need to revisit in a few days. |
blast-hardcheese
force-pushed
the
only-create-distinct-changesets
branch
3 times, most recently
from
199fe0a
to
d67b544
Compare
I don't like this strategy, but I'm interested to see what codecov (and others) think about this approach. I've basically just reimplemented the business logic in the test, but short of mocking out the whole git repo in order to extract state, I'm not sure how best to represent what I'm trying to test.
…l test" This reverts commit ced9ed1.
blast-hardcheese
force-pushed
the
only-create-distinct-changesets
branch
3 times, most recently
from
ef94d73
to
e8067f5
Compare
blast-hardcheese
force-pushed
the
only-create-distinct-changesets
branch
from
e8067f5
to
b1c949d
Compare
|
OK, I think I think the blast radius required to appropriately test this feature ended up being significantly more than initially anticipated, so I humbly submit this for review. The tests needed to be written against real git running on the real filesystem, which is why I had to largely forego Thanks! |
|
It seems to me that this will only delay subsequent PRs with the same changes to the next run. If Scala Steward creates a PR for an update and that PR is not merged before the next run, Scala Steward will not pass that update to I'm also concerned that there is no principle which PR gets created and which PR is prevented. Currently the first update wins over the others and updates are AFAIK sorted by groupId and artifactId. What if a later update would have resulted in a "more correct" PR? |
Only exactly equivalent changesets are deduplicated, using git itself as the final arbiter instead of trying to guess without modifying the filesystem. We accumulate commits, but only gate the push using this approach. To your first point, I didn't realize updates were filtered before hitting NurtureAlg. Short of more back channels with distinct data flows, I don't know how to proceed here. There may be an avenue to pursue, just tracking active branches in the store. This would work in the case you describe, being the initial set of branches to compare against, as well as working in the case of rebasing off master. What do you think about this? |
Attempting to resolve #1995
Problem
Currently, when multiple artifacts share the same version number pinned by the same
valbinding, we end up seeing multiple PRs with the exact same changesetExamples
Strategy in this PR
Attempting to deduplicate before we got to
applyUpdatewasn't a viable strategy, due to the various different heuristics that could result in different commits.Instead, track a
Ref[F, List[Branch]]of every branch that we have walked in this run, then immediately afterapplyUpdatebut beforepushCommits, ensure that there are no branches that we have touched so far in this run that have the same changeset (as determined by the line count ofgit diff other-branch).This will result in a little more IO churn, diffing between every other open and curated branch, but it should have a positive impact on users.
If you've got advice on how to write a more effective test for this new functionality, I'm open to it -- it seemed as though
NurtureAlgTestwould be the right place to put this, but there's not a lot of structure there to base my attempt on.Thank you
As always, a tremendous thank you for this fantastic tool.