You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, there's no metadata around branches, without needing to first consume the event, pull out the URL, fetch the information, and then retrieve all that information.
I propose adding a new branch object field in at least the created change event, but could be argued that it should be in every change event.
"branch": {
"from": "my-fork-branch", # this may need to also support which fork it's coming from, but we can expand on this concept first"to": "main"
}
This would include the branch object with two fields: from and to. The idea would be that from is where the change is coming from, and to is where the change is attempting to be merged. From the comment I mentioned we may need to include fork information or something of that nature, but I think starting simple and expanding once we agree on the from and to names and semantics, we can address the fork specification.
I also noticed that id had some examples of featureBranch1234 as the id, but I think we may be overloading the id in this case and it might not be clear, semantically, on what that should be. Instead, by having the branch object, it becomes very clear on what it is and its purpose
The text was updated successfully, but these errors were encountered:
xibz
changed the title
Branch data in change events
Branch info in change events
Jul 24, 2023
Currently, there's no metadata around branches, without needing to first consume the event, pull out the URL, fetch the information, and then retrieve all that information.
I propose adding a new branch object field in at least the
created
change event, but could be argued that it should be in every change event.This would include the branch object with two fields:
from
andto
. The idea would be thatfrom
is where the change is coming from, andto
is where the change is attempting to be merged. From the comment I mentioned we may need to include fork information or something of that nature, but I think starting simple and expanding once we agree on thefrom
andto
names and semantics, we can address thefork
specification.I also noticed that
id
had some examples offeatureBranch1234
as the id, but I think we may be overloading the id in this case and it might not be clear, semantically, on what that should be. Instead, by having the branch object, it becomes very clear on what it is and its purposeThe text was updated successfully, but these errors were encountered: