This PR adds CI support for the IBM Power Little Endian (ppc64le) architecture. The idea is to ensure that the builds on this architecture are continuously tested along with the Intel builds (amd64) as this is part of the ubuntu distro on that architecture as well and detecting (and fixing) any issues or failures early would help to ensure that we are always up to date. For more info tag @gerrith3

Thanks for the response. We are still working on the Github actions support for the ppc64le. will get back to you when we have that support added.

I tried to set up a webhook rule to be triggered when the payload signature is verified with any one of multiple secrets, but I found that any unsatisfied payload signature sub-rule that appears before other sub-rules in the or rule will cause the parent rule be evaluated to false.

example config:

"trigger-rule": {
      "or": [
        {
          "match": {
            "type": "payload-hash-sha512",
            "secret": "secret-1",
            "parameter": {
              "source": "header",
              "name": "X-Signature"
            }
          }
        },
        {
          "match": {
            "type": "payload-hash-sha512",
            "secret": "secret-2",
            "parameter": {
              "source": "header",
              "name": "X-Signature"
            }
          }
        }
      ]
    },

requests signed by "secret-2" will never trigger the hook because an error will occurred:

error evaluating hook: invalid payload signatures [...]

Closing as a duplicate of #234.

Ok. I don't think this is a duplicate of #471 then.

I think this is, instead, a duplicate of #234. It's been a while since I've looked at #234. @zry98, what are you thoughts on that issue, especially my last comment?

That sounds great.

Ok. I don't think this is a duplicate of #471 then.

I think this is, instead, a duplicate of #234. It's been a while since I've looked at #234. @zry98, what are you thoughts on that issue, especially my last comment?

What version of webhook are you using? If 2.7.0, I suspect this is a duplicate of #471.

Yes, I'm using 2.7.0, please check my reply, if Evaluate returned error will immediately evaluate the parent rule to false.

I've located the reason: https://github.com/adnanh/webhook/blob/9c7f8c1ac4993c56658c4afacda5f3d40630d11e/internal/hook/hook.go#L797-L800

What version of webhook are you using? If 2.7.0, I suspect this is a duplicate of #471.

I tried to set up a webhook rule to be triggered when the payload signature is verified with any one of multiple secrets, but I found that any unsatisfied payload signature sub-rule that appears before other sub-rules in the or rule will cause the parent rule be evaluated to false.

example config:

"trigger-rule": {
      "or": [
        {
          "match": {
            "type": "payload-hash-sha512",
            "secret": "secret-1",
            "parameter": {
              "source": "header",
              "name": "X-Signature"
            }
          }
        },
        {
          "match": {
            "type": "payload-hash-sha512",
            "secret": "secret-2",
            "parameter": {
              "source": "header",
              "name": "X-Signature"
            }
          }
        }
      ]
    },

requests signed by "secret-2" will never trigger the hook because an error will occurred:

error evaluating hook: invalid payload signatures [...]

Hi, I'm trying to receive docker hub webhook using the tool. It looks like docker hub is expecting some json response to determine request should considered successful or not. How can I send response as json?

Example json response would look like:

{
  "state": "success",
  "description": "387 tests PASSED",
  "context": "Continuous integration by Acme CI",
  "target_url": "https://ci.acme.com/results/afd339c1c3d27"
}

Nevermind .. Turns out Docker hub webhook doesn't even check webhook response. It's always success.. I didn't have to send any response at all..

Hi, I'm trying to receive docker hub webhook using the tool. It looks like docker hub is expecting some json response to determine request should considered successful or not. How can I send response as json?

Example json response would look like:

{
  "state": "success",
  "description": "387 tests PASSED",
  "context": "Continuous integration by Acme CI",
  "target_url": "https://ci.acme.com/results/afd339c1c3d27"
}

@adnanh, This PR is a preview of something I've been slowly whittling on. It all started by wanting to fix #393. I needed to be able to access the http.Server from the signal handlers.

This PR doesn't fix #393, but it does lay the groundwork to make that rather easy (see the KPR in the security package). However, there's a lot of changes here which may mean that I need to split this up into smaller steps so that it's easier to review, but I wanted to let you see where I'm headed.

It looks like adding the TLS Curves is a problem in Go 1.14 since the CurveID type didn't support the Stringer interface until Go 1.15. Instead of trying to work around that will build tags, I'll probably wait until Go 1.16 ships, and we can drop Go 1.14. 😃

No rush, but comments are welcome.

To help facilitate new features, begin moving the main webhook service properties to a Service struct.

Add "request" source with support for "method" and "remote-addr" parameters. Both values are taken from the raw http.Request object.

Fixes #312

Fixed

Let's do strings.ToLower(ha.Name) so that we avoid issues with "Method" not being matched :-)

Add "request" source with support for "method" and "remote-addr" parameters. Both values are taken from the raw http.Request object.

Fixes #312

We've actually moved to GitHub Actions in the development branch even though we haven't deleted the Travis config file. It's not clear to me in the GitHub Actions docs if it supports multiple architectures. Any advice?

This PR adds CI support for the IBM Power Little Endian (ppc64le) architecture. The idea is to ensure that the builds on this architecture are continuously tested along with the Intel builds (amd64) as this is part of the ubuntu distro on that architecture as well and detecting (and fixing) any issues or failures early would help to ensure that we are always up to date. For more info tag @gerrith3

+1 to what @moorereason said, you can create a separate repo for this and I can link from the README if you want?

Added some docs and an example to get the request IP :-)

Merged latest development changes, and imeplemented early abort if prehook command fails for any reason. Also renamed Context to PreHook where applicable.

Need docs & examples.