Open LiamClarkeNZ opened 3 years ago
Hey! Happy to hear it's helpful!
I'm assuming it was running after a push to main
? Like you said, rebasing all your commits from the root probably confused GitHub and invalidated the before
field in the event payload of the push
event (https://docs.github.com/en/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#push), and your actions probably "reset" it.
I'm not sure if this edge case can be covered using the data from the push
event, but there might be a way to fall back on something else if the base commit isn't found when fetching data from the API. dco-check doesn't really expect a full/root rebase, and by default it tries not to check all commits from the root commit (at least for GitHub), but perhaps it would be the right behaviour here?
HI @christophebedard - It is indeed an edge case, might not need to be handled in code. I'd be happy to add some brief docs on it. If that works for you, I'd run some more isolated experiments to see which of the changes I made above resolved the issue, so can explain what to do if rebasing from --root and hitting this issue.
Of course, that would be great!
Kia ora,
I added dco-check to GH, thank you for that, it's awesome :), and it flagged that a bunch of my commits weren't DCO compliant, so I rebased from scratch - e.g.,
git rebase -i --root
. In the process, I not only reworded, but also squashed and dropped some commits.This has now broken dco-check, as it seems to be trying to retrieve a commit that no longer exists.
The output:
The actual commits, post rebase:
I'm assuming that state was stored by GH when dco-check cloned the repo, and this confused it. I took the following actions, one of which fixed it, unfortunately I didn't do it in a very scientific manner, my apologies.