you have 2 operations in the spec, publish and subscribe.

above example already tells you what to do as a subscriber, as the document you shared describes an application that publishes a message

you mean Protobuf or what exactly?

protobuf is just the serialization format gRPC is the replacement for HTTP and presumably asynchronous HTTP requests. Still not sure what their point is.

I was wondering how do you use semantic-release tooling in non-js. Do you use ".releaserc" file for config and then on CI execute with npx, to have pure repo with no JS thingy? Or are you just using package.json normally? maybe hidden in ".github" ?

I just use a package.json in the repo root as it doesn't really bother me. It very rarely changes so I pretty much forget its there.

I wanted to also introduce PR title validation, so there is no mistake possible on merging and we follow convetional commits 100% but unfortunately GitHub Actions do not support fork-based workflow properly and those PR checks would be useless :(

Oh, that is unfortunate. Hopefully they fix that. For now, it might be worth writing a little bot that will flag PRs with noncompliant commit messages and titles.

> GitHub Actions do not support fork-based workflow properly

Could you elaborate on this?

Take a look on my blog post about it https://dev.to/derberg/github-actions-when-fascination-turns.... I already reported this to GitHub Actions team and seems they are working on that. For reference https://github.community/t5/GitHub-Actions/GitHub-Action-wor...

Ah yes, fork. My mind read that as branch as we barely ever use forks (enterprise environment and all)

Issue comment-triggered Actions have a write-access GITHUB_TOKEN, unless I’m mistaken. You could implement the /ok-to-test flow with that.

(I’m working on converting some of VSCode’s triage automation to Actions, for reference)

Guy from GitHub suggested the same, but how would you really see such workflow in action? all I have in mind seems so complicated that easier would be to write and host dedicated bot really. Supporting PR on Issue level sounds strange

You install first in your Kubernetes cluster a project build by one of the k8s SIGs called Service Catalog that is capable to connect multiple different brokers into one service offering.

And you can start consuming and manage services exposed through the helm broker, so all the different helm charts that you've bundled into a special package that is compatible with OSBAPI. Here is an example of such packaged helm chart that later on is visible in the catalog https://github.com/kyma-project/addons/tree/master/addons/re...