Open gsaslis opened 1 year ago
In this file it is shown how another process can subscribe to node events. The filtering of the events is the responsibility of said process.
It seems like there is no event pushed specifically for when a patch is updated. We will probably need to enhance the protocol in order to add this functionality.
It seems like there is no event pushed specifically for when a patch is updated.
can we confirm that in #heartwood stream on zulip?
@Archimidis
In this file it is shown how another process can subscribe to node events. The filtering of the events is the responsibility of said process.
isn't this a comment for #2 ?
@Archimidis so, here's what I did:
started a radicle-node for alice
RAD_HOME=~/.radicle_alice
--tracking-policy track --tracking-scope all
started a radicle-node for bob
RAD_HOME=~/.radicle_bob
--tracking-policy track --tracking-scope all
alice tracks bob (with rad track
)
bob tracks alice (with rad track
)
alice creates a new project (git init
/ git add
/ git commit ...
, then rad init
)
bob clones that project (with rad clone
)
git checkout -b some_fix
# make some change to the repo
git add .
git commit -m 'important fix'
alice checks current patches rad patch list
is empty
run rad node events
on alice side and leave that running
bob opens the patch:
# it's important to set `$EDITOR` env var before this. I use IntelliJ as my editor, so: `export EDITOR=idea`
git push rad HEAD:refs/patches
# you'll then type the message for the patch description in $EDITOR
rad node events
I see: {"type":"refs-fetched","remote":"z6MkhDZbG7mJX1oB8ZwAkRavgvGqni6ThePVgnyEEM5nt4Ym","rid":"rad:z3kws2qD51NsDwiXybD7NtnAT49W","updated":[{"created":{"name":"refs/namespaces/z6MkhDZbG7mJX1oB8ZwAkRavgvGqni6ThePVgnyEEM5nt4Ym/refs/heads/patches/d22985c4e81488c85271bac8c7eee79ed9d9e8fe","oid":"5ec3db9c04e8f99ddd3ff2329d0fa194cbb714be"}},{"created":{"name":"refs/namespaces/z6MkhDZbG7mJX1oB8ZwAkRavgvGqni6ThePVgnyEEM5nt4Ym/refs/cobs/xyz.radicle.patch/d22985c4e81488c85271bac8c7eee79ed9d9e8fe","oid":"d22985c4e81488c85271bac8c7eee79ed9d9e8fe"}},{"updated":{"name":"refs/namespaces/z6MkhDZbG7mJX1oB8ZwAkRavgvGqni6ThePVgnyEEM5nt4Ym/refs/rad/sigrefs","old":"cdffb31389a79e96bb7ad0f7fdd20a767e38001c","new":"8d3f30dcff32bea4afd28bbfbe549b22b2a6b114"}}]}
RefsAnnouncement
. In this file it is shown how another process can subscribe to node events. The filtering of the events is the responsibility of said process.
isn't this a comment for https://github.com/gsaslis/radicle-ci-broker/issues/2 ?
That is correct. That particular file is used by the rad node events
command. However, that command just outputs as JSON the events as soon as they are received.
Alright, I missed that RefsAnnouncement
. I'll check this today.
update:
in
{
"type": "refs-fetched",
"remote": "z6MkhDZbG7mJX1oB8ZwAkRavgvGqni6ThePVgnyEEM5nt4Ym",
"rid": "rad:z3kws2qD51NsDwiXybD7NtnAT49W",
"updated": [
{
"created": {
"name": "refs/namespaces/z6MkhDZbG7mJX1oB8ZwAkRavgvGqni6ThePVgnyEEM5nt4Ym/refs/heads/patches/5b10b550d8f3193642162f5d6662f41c12c41b81",
"oid": "d0f5b2589cdd9abf47eb04dded4d530ba9638482"
}
},
{
"created": {
"name": "refs/namespaces/z6MkhDZbG7mJX1oB8ZwAkRavgvGqni6ThePVgnyEEM5nt4Ym/refs/cobs/xyz.radicle.patch/5b10b550d8f3193642162f5d6662f41c12c41b81",
"oid": "5b10b550d8f3193642162f5d6662f41c12c41b81"
}
},
{
"updated": {
"name": "refs/namespaces/z6MkhDZbG7mJX1oB8ZwAkRavgvGqni6ThePVgnyEEM5nt4Ym/refs/rad/sigrefs",
"old": "8d3f30dcff32bea4afd28bbfbe549b22b2a6b114",
"new": "c0401158df4c668ae11db700596034417e57e00c"
}
}
]
}
the oid
in refs/namespaces/z6MkhDZbG7mJX1oB8ZwAkRavgvGqni6ThePVgnyEEM5nt4Ym/refs/heads/patches/5b10b550d8f3193642162f5d6662f41c12c41b81
gives us the commit hash.
We should create a Radicle Patch and watch for the patch node event that is announced through the gossip protocol.
As part of this task we want to find an example of such an event to ensure it has all the data we are looking for: