Gerrit Batch Changes#52647
Conversation
|
|
||
| // Gerrit publishes the Change at push time, and therefore | ||
| if e.ch.ExternalServiceType == extsvc.TypeGerrit { | ||
| exists = false |
There was a problem hiding this comment.
Wanted to call special attention to this "workaround" here, the Changeset "exists" at this point because it gets created at push time, therefore exists would always return true, and we would always enquere a ChangesetUpdate webhook event instead of the regular publish event.
TBH I'm not sure what ramifications this workaround may cause and wanted to point it out, because as far as I can tell everything works well.
There was a problem hiding this comment.
could we move this into the changeset layer and return false for the exists flag from CreateChangeset / CreateDraftChangeset instead? That way, this loop would stay free of implementation details. Also, the description in this comment is clearer to me than the code comment so maybe copy that into the code as well? :)
|
Codenotify: Notifying subscribers in CODENOTIFY files for diff c8f9efa...ab79214.
|
|
I ran through all of the scenarios here, and all of them seem good (with the exception of forks because Gerrit doesn't support it). |
eseliger
left a comment
There was a problem hiding this comment.
I ran through all of the scenarios https://github.com/sourcegraph/sourcegraph/pull/47913#issuecomment-1439155858, and all of them seem good (with the exception of forks because Gerrit doesn't support it).
If forks aren't supported, what happens when the flag is set? Does it error, or just ignore the flag?
|
|
||
| // Gerrit publishes the Change at push time, and therefore | ||
| if e.ch.ExternalServiceType == extsvc.TypeGerrit { | ||
| exists = false |
There was a problem hiding this comment.
could we move this into the changeset layer and return false for the exists flag from CreateChangeset / CreateDraftChangeset instead? That way, this loop would stay free of implementation details. Also, the description in this comment is clearer to me than the code comment so maybe copy that into the code as well? :)
I think my brain must have lagged and not actually finished the comment lol, yeah I'll update it. I can give it a shot for sure, the reason I was hesitant was because the Change technically exists at the time you call CreateChangeset, so I wasn't sure if it might mess with some other logic, but I'll try it out and validate that everything behaves as expected. |
Bundle size report 📦
Look at the Statoscope report for a full comparison between the commits 2d3021b and aa7cc2e or learn more. Open explanation
|
courier-new
left a comment
There was a problem hiding this comment.
👍👍👍👍
Thank you for adding all the tests here too!!!
|
@courier-new thank you for the amazing feedback, I believe I should've addressed all of your suggestions in my most recent commit. |
courier-new
left a comment
There was a problem hiding this comment.
Great changes, left a couple more minor comments.
Another question, since you didn't go this far in your Loom recording: What is the behavior for updating a changeset, like when you go back and execute an updated batch spec that changes the title or produces a different diff and you need to commit and push the new changes? My impression is that it would create a brand new Change on Gerrit, since GenerateGerritChangeID would produce a different ID now. Do we update the tracking okay, i.e. is there still only one Change associated with the batch change after that update? Do we do anything with the old Change on Gerrit/should we?
|
@courier-new I believe I should have addressed all of the comments, the last thing I need to do is validate the scenario when updating the Changeset now that we use the deterministic Change ID approach. I'll update here tomorrow when I look into it. |
|
@courier-new now that we do the deterministic ChangeID, updating the Batch Change (title and script), as you predicted, does create a new Change on the Gerrit code host, but the tracking is not updated locally, so the Batch Change still has the old Change. As you called out, the creation of the new Change is happening because of the deterministic ChangeID generation. My question is, what behavior do we want here? Are we ok with it just creating a new change and we update the Changeset to point to the new Change? Do we want it to still be attached to the old change in which case the deterministic Change ID might be an issue here? I ask because I see for other code hosts we just update the existing PR. |
|
@courier-new I got it to work almost as expected here, it just required messing around a bit with Gerrit's BuildCommitOpts func to use an existing ChangeID instead of generating one if ti exists 😄. |
Closes https://github.com/sourcegraph/sourcegraph/issues/50867 📺 Loom: https://www.loom.com/share/31d7bdace69d4a5ab8c732339f0a4950 I decided to just close the [Reviews PR](https://github.com/sourcegraph/sourcegraph/pull/52470), and open this up instead because as I was connecting everything I noticed quite a few things that weren't right and I thought it would make more sense to just merge the thing that works directly instead of making it a 2-step process. This includes basically everything needed for Gerrit Batch Changes, but not webhooks (we don't know if that will be supported yet). ## Test plan Added tests
Closes https://github.com/sourcegraph/sourcegraph/issues/50867
Closes https://github.com/sourcegraph/sourcegraph/issues/51929
📺 Loom: https://www.loom.com/share/31d7bdace69d4a5ab8c732339f0a4950
I decided to just close the Reviews PR, and open this up instead because as I was connecting everything I noticed quite a few things that weren't right and I thought it would make more sense to just merge the thing that works directly instead of making it a 2-step process.
This includes basically everything needed for Gerrit Batch Changes, but not webhooks (we don't know if that will be supported yet).
Test plan
Added tests