Switch from fmt.Errorf to xerrors.Errorf

[aledbf]

No description provided.

[codecov]

Codecov Report

Merging #5425 (37c832b) into main (4f9aa60) will increase coverage by 6.79%.
The diff coverage is 65.62%.

@@            Coverage Diff             @@
##             main    #5425      +/-   ##
==========================================
+ Coverage   22.98%   29.78%   +6.79%     
==========================================
  Files          11       38      +27     
  Lines        1945     6672    +4727     
==========================================
+ Hits          447     1987    +1540     
- Misses       1439     4501    +3062     
- Partials       59      184     +125     

Flag	Coverage Δ
components-gitpod-cli-app	9.74% <100.00%> (?)
components-ws-daemon-app	22.98% <0.00%> (ø)
components-ws-manager-app	38.35% <69.09%> (?)

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

Impacted Files	Coverage Δ
components/gitpod-cli/cmd/root.go	0.00% <ø> (ø)
components/ws-daemon/pkg/content/archive.go	58.88% <0.00%> (ø)
components/ws-daemon/pkg/content/config.go	62.50% <0.00%> (ø)
components/ws-daemon/pkg/content/initializer.go	0.00% <0.00%> (ø)
components/ws-daemon/pkg/internal/session/store.go	19.38% <ø> (ø)
components/ws-manager/pkg/manager/manager_ee.go	0.00% <ø> (ø)
components/ws-manager/pkg/manager/monitor.go	8.36% <32.00%> (ø)
components/gitpod-cli/cmd/env.go	14.41% <100.00%> (ø)
components/ws-manager/pkg/manager/status.go	73.33% <100.00%> (ø)
... and 26 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 e039c1b...37c832b. Read the comment docs.

[csweichel]

We started using xerrors at the time of the transition to Go 1.13. Once 1.13 was around - and with it the %w verb, Unwrap, etc. we simply did not make the switch back. One of the primary drivers was the stack trackes that xerrors provides, but the default implementation in Go does not.

In most places stack traces make sense, but in some they do not, e.g. ErrNotFound. That said, consistency is a great thing :)

Just one thing: it would be awesome if issues like this made their way through groundwork.

/lgtm
/approve no-issue

[roboquat]

LGTM label has been added.

Git tree hash: c9778dd6bf1a80d90c2d9ef2c1ecedd7dd0ddb7c

[roboquat]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: csweichel

Associated issue requirement bypassed by: csweichel

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [csweichel]
• components/blobserve/OWNERS [csweichel]
• components/content-service/OWNERS [csweichel]
• components/docker-up/OWNERS [csweichel]
• components/ee/agent-smith/OWNERS [csweichel]
• components/ee/kedge/OWNERS [csweichel]
• components/ee/ws-scheduler/OWNERS [csweichel]
• components/gitpod-cli/OWNERS [csweichel]
• components/gitpod-protocol/OWNERS [csweichel]
• components/image-builder/OWNERS [csweichel]
• components/licensor/OWNERS [csweichel]
• components/local-app/OWNERS [csweichel]
• components/registry-facade/OWNERS [csweichel]
• components/registry-facade-api/OWNERS [csweichel]
• components/supervisor/OWNERS [csweichel]
• components/workspacekit/OWNERS [csweichel]
• components/ws-daemon/OWNERS [csweichel]
• components/ws-manager/OWNERS [csweichel]
• components/ws-proxy/OWNERS [csweichel]
• dev/gpctl/OWNERS [csweichel]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment