[1.18] Revert the auto-injecting version changes

[umohnani8]

Signed-off-by: Urvashi Mohnani umohnani@redhat.com

What type of PR is this?

/kind design

What this PR does / why we need it:

Reverting this so we don't run into build issues with
openshift again. We will revisit in master to come up with
a less fragile way of doing this.

Which issue(s) this PR fixes:

Special notes for your reviewer:

Does this PR introduce a user-facing change?

Signed-off-by: Urvashi Mohnani umohnani@redhat.com

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: umohnani8

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 [umohnani8]

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

[codecov]

Codecov Report

Merging #3613 into release-1.18 will not change coverage.
The diff coverage is 0.00%.

@@              Coverage Diff              @@
##           release-1.18    #3613   +/-   ##
=============================================
  Coverage         44.01%   44.01%           
=============================================
  Files               102      102           
  Lines              7827     7827           
=============================================
  Hits               3445     3445           
  Misses             4075     4075           
  Partials            307      307           

[mrunalp]

/lgtm

[cgwalters]

Thanks for the revert; this is stalling RHCOS builds and we're trying to get some other things landed too.

I think gathering version information from git is useful as an informational thing, but it gets fragile if one is trying to actively make decisions based on it. Even without the weird "lookaside cache" case where Koji does that breaks any relationship with the upstream git repo. For example, it's reasonable for downstream project consumers to make their own git repositories and cherry pick patches there - and they shouldn't have to also manage syncing up tags and such.

It's just more robust to do const version = "1.18" in the source code and the cost of doing that is low.

But, it definitely also makes sense to record the git commit, I just wouldn't use it for things like crio-wipe.

[cgwalters]

I also tried setting VERSION=%{version} in our RPM spec build, and I swear it worked once (I verified that ./crio version had a version again) but then failed (still had no version tag) when I tried it a second time...didn't try too hard to debug it though.

[mrunalp]

/retest

[mrunalp]

@lsm for new build once this merges.

[mrunalp]

/test e2e-aws