cib already parses the Git ref to distinguish between changes to branchs and patches, and could maybe do the same to detect tag changes. Assuming the Radicle node emits a RefsFetched event with a relevant update.
cib
cibtool event record while pushing a tag to a repository would be a way to see this.
cibtool event record
I tested this:
cibtool event record --output node-event.log
git tag -sam "test tag" v0.0.0
git push --tags rad
git tag -sam "test tag" v0.0.0 c0b4b6b5792140fbbc3e59cc31de329d909894d6
-f
Result:
Node emits a RefsFetched event with an update that looks like any other ref update:
RefsFetched
{ "created": { "name": "refs/namespaces/z6MkgEMYod7Hxfy9qCvDv5hYHkZ4ciWmLFgfvm3Wn1b2w2FV/refs/tags/v0.0.0", "oid": "0136ea60433f4f2a66034f60522833d8b9c77224" } }
I can change the Ci broker to cope with this.
Tag events are now supported.
cibalready parses the Git ref to distinguish between changes to branchs and patches, and could maybe do the same to detect tag changes. Assuming the Radicle node emits a RefsFetched event with a relevant update.cibtool event recordwhile pushing a tag to a repository would be a way to see this.I tested this:
cibtool event record --output node-event.loggit tag -sam "test tag" v0.0.0), then push (git push --tags rad)git tag -sam "test tag" v0.0.0 c0b4b6b5792140fbbc3e59cc31de329d909894d6), then push again (with-f)Result:
Node emits a
RefsFetchedevent with an update that looks like any other ref update:I can change the Ci broker to cope with this.
Tag events are now supported.