Improve version information in downstream Argo CD build

Epic Goal

To improve the version information that is returned by Argo CD's /api/version endpoint, so people are less confused looking at it. Also, we want to be able to specify additional information in our builds that may not be part of the upstream's version information.

Why is this important?

The upstream Argo CD /api/version endpoint currently displays the build's Git (shortened) commit SHA and status (e.g. "clean" or "dirty") with the version of both, server and CLI, e.g. v2.5.11-3b25a8f. This can be used to quickly identify what commit a specific version was built from, and whether there may have been local non-commited changes (when the state is "dirty").

The /api/version endpoint for our downstream build of Argo CD currently displays something along the lines:

v2.5.11-unknown

Also, distributors with a downstream version (like us) need a way to provide some additional information in the version info returned by the /api/version endpoint.

The goal is to have users as well as support engineers more quickly and reliably figuring out which exact version and build of Argo CD is running on the cluster.

Scenarios

1. ...

Acceptance Criteria (Mandatory)

• Our builds show the commit SHA from the upstream's repository that we built the downstream version from, instead of "unknown", in the version string
• The Argo CD version endpoint is extended to contain an additional (optional) field for vendors to populate during build.
  • This field could be called BuildInfo or ExtraBuildInfo or something along these lines
  • Its value is set by a linker parameter, similar to how the commit SHA can already be set
  • The value itself should reflect that this is a Red Hat build, and should include some information about our build

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. …

Open questions::

1. …

Done Checklist

• Acceptance criteria are met
• Non-functional properties of the Feature have been validated (such as performance, resource, UX, security or privacy aspects)
• User Journey automation is delivered
• Support and SRE teams are provided with enough skills to support the feature in production environment