Home Original page

Correctly split MCP registry update to it’s own workflow. by Ferroin · Pull Request #21089 · netdata/netdata

@Ferroin 

This needs to trigger when your releases are actually published, not
when we start the release process, so it needs to have it’s own workflow
with a release trigger instead of being part of the release workflow (as
we always manually publish the release on GitHub).

This actually simplifies a couple of parts of the job as well, since the
`release` event defaults to using the commit of the release that
triggered the workflow when checking out the repository.

@Ferroin Ferroin marked this pull request as ready for review

October 2, 2025 17:02

@Ferroin

stelfrag pushed a commit to stelfrag/netdata that referenced this pull request

Oct 27, 2025 
)

* Correctly split MCP registry update to it’s own workflow.

This needs to trigger when your releases are actually published, not
when we start the release process, so it needs to have it’s own workflow
with a release trigger instead of being part of the release workflow (as
we always manually publish the release on GitHub).

This actually simplifies a couple of parts of the job as well, since the
`release` event defaults to using the commit of the release that
triggered the workflow when checking out the repository.

* Address review comments.

(cherry picked from commit 81acfc8)

Ferroin added a commit that referenced this pull request

Oct 28, 2025 
* Correctly split MCP registry update to it’s own workflow.

This needs to trigger when your releases are actually published, not
when we start the release process, so it needs to have it’s own workflow
with a release trigger instead of being part of the release workflow (as
we always manually publish the release on GitHub).

This actually simplifies a couple of parts of the job as well, since the
`release` event defaults to using the commit of the release that
triggered the workflow when checking out the repository.

* Address review comments.

(cherry picked from commit 81acfc8)