Headless Logs III: Upload and retrieve headless logs after the workspaces has stopped

[geropl]

Test

Run prebuild and download log

• Add env var: https://gpl-headless-log-content.staging.gitpod-dev.com/variables , with PREBUILD_PARAMS=100_1s_10s_success for gitpod-io/gitpod
• Run prebuild: https://gpl-headless-log-content.staging.gitpod-dev.com/#prebuild/https://github.com/gitpod-io/gitpod/tree/gpl/test-prebuild
• Find out the instanceId from the prebuild (for instance select * from d_b_prebuilt_workspace)
• Open Browser Console on your dashboard tabs and paste await window._gp.gitpodService.server.getHeadlessLog("|instanceId|")
• Download the log file from the presented URL

ToDo

• upload logs
• provide access via content service
• serve from /headless-logs/ (depends on Headless log I: Server #4262 being merged)

[codecov]

Codecov Report

Merging #4439 (1a04547) into main (974ce0a) will increase coverage by 35.96%.
The diff coverage is 9.41%.

❗ Current head 1a04547 differs from pull request most recent head 823952c. Consider uploading reports for the commit 823952c to get more accurate results

@@            Coverage Diff            @@
##           main    #4439       +/-   ##
=========================================
+ Coverage      0   35.96%   +35.96%     
=========================================
  Files         0       78       +78     
  Lines         0    15481    +15481     
=========================================
+ Hits          0     5568     +5568     
- Misses        0     9429     +9429     
- Partials      0      484      +484     

Flag	Coverage Δ
components-content-service-app	14.35% <11.02%> (?)
components-content-service-lib	14.35% <11.02%> (?)
components-ee-ws-scheduler-app	62.84% <ø> (?)
components-image-builder-api-go-lib	∅ <ø> (?)
components-image-builder-app	34.44% <ø> (?)
components-supervisor-app	36.37% <66.66%> (?)
components-workspacekit-app	∅ <ø> (?)
components-ws-daemon-api-go-lib	∅ <ø> (?)
components-ws-daemon-app	22.29% <0.00%> (?)
components-ws-daemon-nsinsider-app	∅ <ø> (?)
components-ws-manager-api-go-lib	∅ <ø> (?)
components-ws-manager-app	36.63% <0.00%> (?)
components-ws-proxy-app	65.84% <ø> (?)
dev-loadgen-app	∅ <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
components/content-service/pkg/storage/gcloud.go	3.11% <0.00%> (ø)
components/content-service/pkg/storage/minio.go	0.00% <0.00%> (ø)
components/content-service/pkg/storage/noop.go	0.00% <0.00%> (ø)
components/content-service/pkg/storage/storage.go	7.69% <0.00%> (ø)
components/ws-daemon/pkg/content/initializer.go	0.00% <0.00%> (ø)
components/ws-daemon/pkg/content/service.go	0.00% <0.00%> (ø)
components/ws-manager/pkg/manager/monitor.go	0.00% <0.00%> (ø)
...ontent-service/pkg/service/headless-log-service.go	24.13% <24.13%> (ø)
components/supervisor/pkg/supervisor/tasks.go	47.98% <66.66%> (ø)
components/ws-manager/pkg/manager/metrics.go	11.26% <0.00%> (ø)
... and 77 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 974ce0a...823952c. Read the comment docs.

[geropl]

/werft run

👍 started the job as gitpod-build-gpl-headless-log-content.20

[csweichel]

This is in excellent shape! I have yet to try things out, and would much prefer more tests, but we're really rather close here :)

[csweichel]

unit tests for the HeadlessLogService would be awfully nice - e.g. by mocking PresignedAccess

[geropl]

I added a test for ListLogs. Not super convinced that the test alone justifies the LOC of the mock... but maybe useful for the other services as well.

[csweichel]

We've made the switch from this "legacy" naming convention to what we use today about nine months ago - I reckon we could get rid of it.

Not necessarily as part of this PR, only if it makes you life/this code easier.

[geropl]

Not 100% this PR, but closely related:
@svenefftinge Discovered yesterday that the current implementation still needs quite some time (e.g., 1 db-sync cycle after the pod got created) to be able to connect to a running prebuild because we need to know the ideURL to derive the supervisor URL from it.

We could try to improve a bit by storing the URL from the StartWorkspaceResponse we already get directly into the DB (here) but still depend on a sync cycle.

[csweichel]

Thank you for sticking with this PR for so long. Let's get this in