feat: introduces a new resource "http"

[dduportal]

Implements #268

This PR introduces a new resource of type http with source and condition capability.

The initial UX proposal has been updated to ensure separation between source and condition are easier (see the E2E test).

Here is a "complete reference example":

sources:
  getWithCustomRequest:
    kind: http
    spec:
      url: https://repo.jenkins-ci.org/releases/org/jenkins-ci/main/jenkins-war/maven-metadata.xml
      request:
        headers:
          Authorization: 'Bearer Token'
          Accept: 'application/xml'
        verb: GET

conditions:
  checkWithCustomRequest:
    kind: http
    sourceid: getJenkinsWarArtifactMetadatas
    spec:
      url: https://repo.jenkins-ci.org/releases/org/jenkins-ci/main/jenkins-war/maven-metadata.xml
      request:
        headers:
          Authorization: 'Bearer Token'
          Accept: 'application/xml'
        verb: HEAD
      responseasserts:
        statuscode: 302
        headers:
          Content-Type: "text/html; charset=utf-8"

Test

To test this pull request, you can run the following commands:

cd ./pkg/plugins/resources/updateclihttp/
go test

Additional Information

• For a source, both HTTP/4xx and HTTP/5xx response status code are considered a failure (as both client and server side errors are not expected to provide a body). This behavior can be adapted on a subsequent PR if we have a use case to retrieve a body on a HTTP/404 error.
• For a condition there are 2 cases:
  • If no assertion is provided, HTTP/5xx is considered an error, while HTTP/4xx is considered a non passing condition.
  • If assertion is provided, then the status code is compared to the provided status code assertion

[olblak]

This plugin is awesome. I tested locally and it works great.
I also like the unit tests

I made a few suggestion to the plugin comment as I think they can be improve a bit but it's not a blocker

I am just wondering how we should communicate if it's better to fetch content using the http plugin or the file with the http protocol in the path

Feel free to resolve the conversations and the merge whenever you want

[dduportal]

This plugin is awesome. I tested locally and it works great. I also like the unit tests

I made a few suggestion to the plugin comment as I think they can be improve a bit but it's not a blocker

Thanks! I've taken your suggestions. If you see further improvement (on the comment particularly) don't hesitate to comment the PR, even if merged: i'll send a subsequent PR if need be.

I am just wondering how we should communicate if it's better to fetch content using the http plugin or the file with the http protocol in the path

Proposal, WDYT?

• Recommended to use http for cases where the whole body is required and/or when the HTTP request need to be customized (e.g. adding headers for authentication/cache/etc.)
• Recommended to use file if you want to apply a pattern matching (for instance https://github.com/jenkins-infra/jenkins-infra/blob/297dd8ab1d9b897710f73bb10387c50e7b440df8/updatecli/weekly.d/jenkinscontroller-tools-maven.yaml#L25-L32)

[dduportal]

Self merging because:

Feel free to resolve the conversations and the merge whenever you want

from @olblak

and I only changed comments since his last review