Originally created by @Jisagi on GitHub (Jun 2, 2025).
Hi, I recently switch from portainer to komodo and I don't look back at all so far. The only "feature" I could not fully replicate compared to portainer is the webhook redeployment of stacks. Portainer had a webhook that does not need a payload, komodo on the other hand does. The problem I ran into, is the release event gitlab provides. The others I tested (push and deployment) work just fine, but the release event throws the following error when I check the komodo logs:
2025-06-02T11:12:06.982892Z WARN StackWebhook{id="some-service"}: core::listener::router: Failed at running webhook for stack some-service | Failed to parse gitlab request body: missing field `ref` at line 1 column 1992
tag even error see below
I could not find any info on what komodo actually needs inside the payload to manually send a request to komodo and skip the whole gitlab webhook part.
Either way, this Issue has two parts:
Release&Tag webhook events from gitlab do not work
Does the webhook call to komodo actually need the info from the payload and/or would it be possible to have a (separate?) webhook that is callable w/o a payload?
EDIT: Why I am not using other webhook events?
Push: The pipeline needs to build the new image first, so push cannot work
Deployment: Does technically work, but it triggers twice. Once when the deployment job starts and once when it ends. Two webhook calls are unnecessary. This is my current workaround
Tag: Fails with a different error request branch does not match expected
Pipeline: Trigger gods knows how often, even worse than deployment
Everything else does not fit my use case of redeploying a stack in the last pipeline job
My preferred solution would be the release event, but a payload-less webhook as portainer has it would also be an option, albeit probably more work on your end.
EDIT2:
My newest workaround is more like an alternative solution by adding another ci job that calls the komodo api directly with DeployStackLink and forcing a pull&deploy of the whole stack. It does need an additional ci job and eliminates the need for the webhook alltogether, but the problem with webhook itself still persists. So I do have something that does works for me now, but I will keep the issue open nontheless, for everyone else who expects the (gitlab) webhook to work with these events (release/tag and maybe others, i did not test all of them).
Originally created by @Jisagi on GitHub (Jun 2, 2025).
Hi, I recently switch from portainer to komodo and I don't look back at all so far. The only "feature" I could not fully replicate compared to portainer is the webhook redeployment of stacks. Portainer had a webhook that does not need a payload, komodo on the other hand does. The problem I ran into, is the release event gitlab provides. The others I tested (push and deployment) work just fine, but the release event throws the following error when I check the komodo logs:
```
2025-06-02T11:12:06.982892Z WARN StackWebhook{id="some-service"}: core::listener::router: Failed at running webhook for stack some-service | Failed to parse gitlab request body: missing field `ref` at line 1 column 1992
tag even error see below
```
I could not find any info on what komodo actually needs inside the payload to manually send a request to komodo and skip the whole gitlab webhook part.
Either way, this Issue has two parts:
1. Release&Tag webhook events from gitlab do not work
2. Does the webhook call to komodo actually need the info from the payload and/or would it be possible to have a (separate?) webhook that is callable w/o a payload?
EDIT: Why I am not using other webhook events?
- Push: The pipeline needs to build the new image first, so push cannot work
- Deployment: Does technically work, but it triggers twice. Once when the deployment job starts and once when it ends. Two webhook calls are unnecessary. This is my current workaround
- Tag: Fails with a different error `request branch does not match expected`
- Pipeline: Trigger gods knows how often, even worse than deployment
- Everything else does not fit my use case of redeploying a stack in the last pipeline job
My preferred solution would be the release event, but a payload-less webhook as portainer has it would also be an option, albeit probably more work on your end.
EDIT2:
My newest workaround is more like an alternative solution by adding another ci job that calls the komodo api directly with `DeployStack` [Link](https://docs.rs/komodo_client/latest/komodo_client/api/execute/struct.DeployStack.html) and forcing a pull&deploy of the whole stack. It does need an additional ci job and eliminates the need for the webhook alltogether, but the problem with webhook itself still persists. So I do have something that does works for me now, but I will keep the issue open nontheless, for everyone else who expects the (gitlab) webhook to work with these events (release/tag and maybe others, i did not test all of them).
GiteaMirror
added the bug label 2026-03-22 17:15:09 -05:00
2025-06-06T10:27:53.219194727Z 2025-06-06T10:27:53.218978Z WARN StackWebhook{id="service"}: core::listener::router: Failed at running webhook for stack service | Failed to parse github request body: missing field `ref` at line 1 column 9560
2025-06-06T10:27:53.238603150Z 2025-06-06T10:27:53.238389Z WARN StackWebhook{id="service"}: core::listener::router: Failed at running webhook for stack service | Failed to parse github request body: missing field `ref` at line 1 column 9562
2025-06-06T10:27:53.245763410Z 2025-06-06T10:27:53.245625Z WARN StackWebhook{id="service"}: core::listener::router: Failed at running webhook for stack service | Failed to parse github request body: missing field `ref` at line 1 column 9561
2025-06-06T10:27:54.486322342Z 2025-06-06T10:27:54.486156Z WARN StackWebhook{id="service"}: core::listener::router: Failed at running webhook for stack service | Failed to parse github request body: missing field `ref` at line 1 column 14517
@Notexe commented on GitHub (Jun 6, 2025):
I'm having the same issue with github's releases:
```
2025-06-06T10:27:53.219194727Z 2025-06-06T10:27:53.218978Z WARN StackWebhook{id="service"}: core::listener::router: Failed at running webhook for stack service | Failed to parse github request body: missing field `ref` at line 1 column 9560
2025-06-06T10:27:53.238603150Z 2025-06-06T10:27:53.238389Z WARN StackWebhook{id="service"}: core::listener::router: Failed at running webhook for stack service | Failed to parse github request body: missing field `ref` at line 1 column 9562
2025-06-06T10:27:53.245763410Z 2025-06-06T10:27:53.245625Z WARN StackWebhook{id="service"}: core::listener::router: Failed at running webhook for stack service | Failed to parse github request body: missing field `ref` at line 1 column 9561
2025-06-06T10:27:54.486322342Z 2025-06-06T10:27:54.486156Z WARN StackWebhook{id="service"}: core::listener::router: Failed at running webhook for stack service | Failed to parse github request body: missing field `ref` at line 1 column 14517
```
If you are still having this issue, double check and make sure your webhook is setup with content-type application/json. The default application/x-www-form-urlencoded will throw this same error.
@calebcall commented on GitHub (Sep 21, 2025):
If you are still having this issue, double check and make sure your webhook is setup with content-type application/json. The default application/x-www-form-urlencoded will throw this same error.
Even with content-type set to application/json I still get Failed to parse github request body: missing field ref at line 1 column 9615 in komodo's logs
@Notexe commented on GitHub (Sep 22, 2025):
Even with content-type set to application/json I still get `Failed to parse github request body: missing field `ref` at line 1 column 9615` in komodo's logs
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @Jisagi on GitHub (Jun 2, 2025).
Hi, I recently switch from portainer to komodo and I don't look back at all so far. The only "feature" I could not fully replicate compared to portainer is the webhook redeployment of stacks. Portainer had a webhook that does not need a payload, komodo on the other hand does. The problem I ran into, is the release event gitlab provides. The others I tested (push and deployment) work just fine, but the release event throws the following error when I check the komodo logs:
I could not find any info on what komodo actually needs inside the payload to manually send a request to komodo and skip the whole gitlab webhook part.
Either way, this Issue has two parts:
EDIT: Why I am not using other webhook events?
request branch does not match expectedMy preferred solution would be the release event, but a payload-less webhook as portainer has it would also be an option, albeit probably more work on your end.
EDIT2:
My newest workaround is more like an alternative solution by adding another ci job that calls the komodo api directly with
DeployStackLink and forcing a pull&deploy of the whole stack. It does need an additional ci job and eliminates the need for the webhook alltogether, but the problem with webhook itself still persists. So I do have something that does works for me now, but I will keep the issue open nontheless, for everyone else who expects the (gitlab) webhook to work with these events (release/tag and maybe others, i did not test all of them).@Notexe commented on GitHub (Jun 6, 2025):
I'm having the same issue with github's releases:
@calebcall commented on GitHub (Sep 21, 2025):
If you are still having this issue, double check and make sure your webhook is setup with content-type application/json. The default application/x-www-form-urlencoded will throw this same error.
@Notexe commented on GitHub (Sep 22, 2025):
Even with content-type set to application/json I still get
Failed to parse github request body: missing fieldrefat line 1 column 9615in komodo's logs