display logs for verifications/analyses that take the form of a job

[krancour]

We're not going to get into the business of forwarding and storing logs, but @jessesuen has proposed that we allow operators to specify a URL template that can produce URLs as a function of stage, promotion name, freight name, analysis run name, etc., along with auth headers.

This can be used to enable a new API server endpoint to act as a proxy for logs that are accessible via an https get request.

The UI, and possibly the CLI, can make use of the new endpoint to expose verifications/analyses to users.

Ultimately, this would mean that if you can manage to ship your logs to object storage (for instance), Kargo can display them.

[blakestoddard]

I scoop up logs from all pods in a cluster and send them to a central store where they're queryable by pod name (Loki) -- having the name of the job (or the child pod itself) that Argo Rollouts kicks off would be great:

status.metricResults[...]measurements.metadata.job-name

status:
. . .
  metricResults:
  - consecutiveSuccess: 1
    count: 1
    measurements:
    - finishedAt: "2025-03-11T05:47:26Z"
      metadata:
        job-name: f4a3e538-f183-4d9d-b23f-a5a55ba54bda.integration-test.1
        job-namespace: test-service
. . .

[antoine-sncf]

In our case we use the jobs to run roboframework tests.
And, as we cannot have an output in kargo we currently use gitlab pages to store the full report but that's not exactly the same use-case.
Having the logs would help in debugging but having a link of this roboframework report from kargo's stage to access this document would be required (is there an issue about this one already?).
argocd has an external link attribut on applications where we can set fixed links

[krancour]

we currently use gitlab pages to store the full report

but that's not exactly the same use-case

I'm not sure how that isn't the same use case, unless perhaps what's being stored are not raw logs, but something different like a report formatted with HTML or something.

Can you clarify?

[blakestoddard]

If you use something like Allure and generate an HTML report that gets thrown in S3, you could link to it (not sure how you'd handle auth for that though).

[antoine-sncf]

Yup, in my case it's an html report generated by roboframework,
(example from roboframework website)

and as we don't use Allure we store it on gitlab pages (within each project's repositories) and as @blakestoddard identified handling auth could be a big nightmare (the report shouldn't be a public page), and therefore just having a link to get to the report would be a first step.

but having robotframework logs is also part of the requirement (logs & final report are 2 things)

Edit: external url & auth for logs (i don't know if a single call works with gitlab pages)
& external url & auth for "html report" OR just external url displayed in the UI at the stage("last verification status"/verification level (how to handle each verification history ?)

Edit2: lol "freshly merged" Gitlab : Programmatic access to private pages

[krancour]

As proposed, this is strictly about logs and not reports. Displaying reports within the UI or CLI does not make sense in the same way that displaying raw logs would. Linking to external reports in a separate browser tab seems useful and doable, but also seems like a separate feature from what's proposed here and I'd rather keep the scope of this issue narrow. (Feel free to open a separate issue.)

where do we store things if it should be private

There are some minor details to work out here, but in general, you could expect it to work the same as everything else in Kargo. Permissions are described using pure Kubernetes RBAC. The API server may have unconditional access to all the logs, but the endpoint that proxies them would perform a subject access review to verify the user's authority to view them.

[krancour]

Closed by #3678 and #3682.