登录
首页 >  Golang >  Go问答

强制 Gitlab 在 Go 失败时重试 Webhook

来源:stackoverflow

时间:2024-04-23 15:03:33 345浏览 收藏

一分耕耘,一分收获!既然打开了这篇文章《强制 Gitlab 在 Go 失败时重试 Webhook》,就坚持看下去吧!文中内容包含等等知识点...希望你能在阅读本文后,能真真实实学到知识或者帮你解决心中的疑惑,也欢迎大佬或者新人朋友们多留言评论,多给建议!谢谢!

问题内容

我想监视 Gitlab 项目中的每个事件并将它们存储在外部服务中。为此,我使用 Gitlab Webhooks。我用 Go 创建了一个小型本地 HTTP 服务器,用于监听 Gitlab 的 POST 并将其转发到外部服务。 Hooks 包含我需要的所有信息,因此看起来这个架构很好:

Gitlab > HTTPServer > 外部服务。

我的问题是当外部服务关闭时,我无法设法让 Gitlab 重试失败的请求。正如文档所述:

  • GitLab 会忽略您的端点返回的 HTTP 状态代码。
  • 您的端点应始终返回有效的 HTTP 响应。如果您不这样做,GitLab 将认为挂钩失败并重试。

令人惊讶的是,Gitlab 没有适当的方法来请求 webhook 重试。我必须明确返回无效的 http 响应。此外,我找不到 API 端点来列出所有失败的 Webhook 并请求重新发送。

问题:如何使用标准“net/http”库显式返回无效的 HTTP 响应,以强制 Gitlab 重试 Webhooks?


解决方案


正如评论中所写,webhook 只是事件发生的通知,并且可能会发送一些数据(通常为 json 数据)。

您有责任保留事件本身以及您想要/需要处理随事件一起发送的数据。您将在下面找到一个带注释的示例。请注意,这不包括增量退避,但这应该很容易添加:

package main

import (
    "encoding/json"
    "flag"
    "io"
    "log"
    "net/http"
    "os"
    "path/filepath"

    "github.com/joncrlsn/dque"
)

var (
    bind        string
    queuedir    string
    segmentsize int
)

// you might want to add request headers and stuff
type webhookcontent struct {
    foo string
    bar int
}

func init() {
    flag.stringvar(&bind, "bind", ":8080", "the address to bind to")
    flag.stringvar(&queuedir, "path", "./queue", "path to store the queue in")
    flag.intvar(&segmentsize, "size", 50, "number of entries for the queue")
}

// the "webserver" component
func runserver(q *dque.dque) {

    http.handlefunc("/webhook", func(w http.responsewriter, r *http.request) {
        // a new decoder for each call, as we want to have a new limitreader
        // for each call. this is a simple, albeit a bit crude method to prevent
        // accidental or malicious overload of your server.
        dec := json.newdecoder(io.limitreader(r.body, 4096))

        defer r.body.close()

        c := &webhookcontent{}
        if err := dec.decode(c); err != nil {
            log.printf("reading body: %s", err)
            http.error(w, "internal error", http.statusinternalservererror)
            return
        }

        // when the content is successfully decoded, we can persist it into
        // our queue.
        if err := q.enqueue(c); err != nil {
            log.printf("enqueueing webhook data: %s", err)
            // proper error handling is missing here
        }
    })

    http.listenandserve(bind, nil)
}

func main() {
    flag.parse()

    var (
        q   *dque.dque
        err error
    )

    if !direxists(queuedir) {
        if err = os.mkdirall(queuedir, 0750); err != nil {
            log.fatalf("creating queue dir: %s", err)
        }
    }

    if !direxists(filepath.join(queuedir, "webhooks")) {
        q, err = dque.new("webhooks", queuedir, segmentsize, func() interface{} { return &webhookcontent{} })
    } else {
        q, err = dque.open("webhooks", queuedir, segmentsize, func() interface{} { return &webhookcontent{} })
    }

    if err != nil {
        log.fatalf("setting up queue: %s", err)
    }

    defer q.close()

    go runserver(q)

    var (
        // placeholder during event loop
        i interface{}
        // payload
        w *webhookcontent
        // did the type assertion succeed
        ok bool
    )

    for {
        // we peek only. the semantic of this is that
        // you can already access the next item in the queue
        // without removing it from the queue and "mark" it as read.
        // we use peekblock since we want to wait for an item in the
        // queue to be available.
        if i, err = q.peekblock(); err != nil {
            // if we can not peek, something is seriously wrong.
            log.fatalf("reading from queue: %s", err)
        }

        if w, ok = i.(*webhookcontent); !ok {
            // if the type assertion fails, something is seriously wrong, too.
            log.fatalf("reading from queue: %s", err)
        }

        if err = dosomethinguseful(w); err != nil {
            log.printf("something went wrong: %s", err)
            log.println("i strongly suggest entering an incremental backoff!")
            continue
        }

        // we did something useful, so we can dequeue the item we just processed from the queue.
        q.dequeue()
    }

}

func dosomethinguseful(w *webhookcontent) error {
    log.printf("instead of this log message, you can do something useful with: %#v", w)
    return nil
}

func direxists(path string) bool {
    fileinfo, err := os.stat(path)
    if err == nil {
        return fileinfo.isdir()
    }
    return false
}

现在,当您执行以下操作时:

$ curl -x post --data '{"foo":"baz","bar":42}' http://localhost:8080/webhook

你应该得到一个类似的日志条目

2020/04/18 11:34:23 Instead of this log message, you can do something useful with: &main.webhookContent{Foo:"Baz", Bar:42}

请注意,see GitLab 15.7(2022 年 12 月)实现了相反方法:

因此,从 gitlab 15.7+ 开始,不仅发回“无效的 http 响应”不起作用,还会导致 webhook 被禁用。

GitLab 15.10(2023 年 3 月)对此进行了改进

今天关于《强制 Gitlab 在 Go 失败时重试 Webhook》的内容就介绍到这里了,是不是学起来一目了然!想要了解更多关于的内容请关注golang学习网公众号!

声明:本文转载于:stackoverflow 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>