❗ GitHub → Taiga webhook via GitHub Actions not triggering any updates

Hi everyone!

I want to configure a GitHub webhook that triggers only for the main branch.
I’m trying to trigger a Taiga webhook from a GitHub Actions workflow whenever I push to the main branch — but although Taiga returns 204 No Content, nothing actually happens inside the Taiga project (no new post).

(I’m on the web version of Taiga)

Here is my workflow:

name: Notify Taiga on main push

on:
  push:
    branches: ["main"]

permissions:
  contents: read

jobs:
  notify:
    runs-on: ubuntu-latest

    steps:
      - name: Copy GitHub event payload
        run: cp "$GITHUB_EVENT_PATH" payload.json

      - name: Compute SHA1 signature
        id: sig
        env:
          TAIGA_WEBHOOK_SECRET: ${{ secrets.TAIGA_WEBHOOK_SECRET }}
        run: |
          SIG=$(python3 -c "import hmac, hashlib, os; secret=os.environ['TAIGA_WEBHOOK_SECRET'].encode(); data=open('payload.json','rb').read(); print(hmac.new(secret,data,hashlib.sha1).hexdigest())")
          echo "Computed signature: $SIG"
          echo "signature=sha1=$SIG" >> $GITHUB_OUTPUT

      - name: Send payload to Taiga
        env:
          TAIGA_WEBHOOK_URL: ${{ secrets.TAIGA_WEBHOOK_URL }}
          SIGNATURE: ${{ steps.sig.outputs.signature }}
        run: |
          echo "Sending with signature: $SIGNATURE"
          curl -v "$TAIGA_WEBHOOK_URL" \
            -H "Content-Type: application/json" \
            -H "X-Hub-Signature: $SIGNATURE" \
            --data-binary @"payload.json"

:yellow_circle: Question:
Has anyone successfully triggered Taiga’s github-hook endpoint from GitHub Actions?
Does Taiga require a specific subset of GitHub events or headers?
Is the 204 response normal even when the event is ignored?

Any hints or examples would be super helpful :folded_hands:

any solutions!?

may be for selfhost taiga? (idk mb need transfer to selfhost for right working all services…)

Yes, this one is a little sneaky. 204 from Taiga is normal, even when it silently drops the event. It really just means “received,” not “processed.”

A few things that people often get wrong with the GitHub → Taiga webhook are:

Taiga’s GitHub hook is only looking for certain types of events. Push works, but only if the payload structure is what Taiga expects. This is because it was built around GitHub’s native webhook and not Actions-generated ones. The payloads of actions can be a little different.

Taiga expects the X-Hub-Signature header to be exactly right, but it also thinks the payload hasn’t been changed. It can ignore the event silently if you change anything, even whitespace.

You set the Content-Type to application/json, which is good, but Taiga also needs X-GitHub-Event. Without it, it often doesn’t do anything. It doesn’t give an error; it just gives a 204.

Webhook handling is much stricter for self-hosted Taiga. You will get the same behavior if the events service isn’t fully wired or the background workers aren’t running.

Quick test: send a raw GitHub webhook from the repo settings to the same Taiga endpoint. If that works but Actions doesn’t, it’s definitely a mismatch between the payload and the header.

It’s also important to note that Taiga hasn’t really kept up with how GitHub webhooks work now, so this is a known problem.

In short, 204 doesn’t mean success; it just means Taiga didn’t crash. Check the X-GitHub-Event, the shape of the payload, and if you’re hosting it yourself with workers running.