Bug 1662263

Evan,

> The git commit matches the git repo that the image was built from. For OSE, that means the commit in the dist-git repo.
> You can use it to trace it to the code that was actually used to build the image.

Yeah, but as an end user, how can they trace the code according to the build commit info?
It would be better if we let the downstream image output the PR commit info as we did for the upstream image.
I guess this is quite similar to bug 1626434.

Tim

> Try inspecting the image itself directly.

Yes, thanks, I know. I described it in comment 7. But, the customer could get the auth of the image registry?

Luke,

> however I'm not sure how to feel about putting it in *all* the images we build.

Yeah, understood. But, I think the customer prefers the source commits as the "olm --version" output. Because the dist-git commits make no sense for them.
I insist the better user experience is the first. I think we should address this issue. We can delay it to the 4.1 if we cannot address it in 4.0.

(In reply to Jian Zhang from comment #10)
> Tim
> 
> > Try inspecting the image itself directly.
> 
> Yes, thanks, I know. I described it in comment 7. But, the customer could
> get the auth of the image registry?

My mistake, I missed that comment.

> Luke,
> 
> > however I'm not sure how to feel about putting it in *all* the images we build.
> 
> Yeah, understood. But, I think the customer prefers the source commits as
> the "olm --version" output. Because the dist-git commits make no sense for
> them.

That's correct, they would not make any sense to them.

> I insist the better user experience is the first. I think we should address
> this issue. 

You're absolutely right. From a customer standpoint it is simply confusing and misleading.

> We can delay it to the 4.1 if we cannot address it in 4.0.

I think 4.1 will be realistic. We need to create a card for this so we don't lose track of the work. I will add one to our backlog presently.

Card is here https://jira.coreos.com/browse/ART-465 filling details this morning.

Wrong card, this is your card: https://jira.coreos.com/browse/ART-460

Tim,

Many thanks for your understanding! I change the Target Release to "4.1.0". Correct me if I'm wrong.

(In reply to Jian Zhang from comment #14)
> Tim,
> 
> Many thanks for your understanding! I change the Target Release to "4.1.0".
> Correct me if I'm wrong.

That's perfect Jian. And thanks for sending us this bug. It'll improve the overall product when we can start working on a fix :-)

*** Bug 1626434 has been marked as a duplicate of this bug. ***

This experience will be improved by ART processes in https://jira.coreos.com/browse/ART-460

Reopen it since we should have a bug in BZ to trace this issue.

Looks good to me, verify it, thanks all!

Cluster version is 4.2.0-0.nightly-2019-07-28-222114

We can see, the git commit is `d2209c409b35f1db4669c474044decc6995f624d`, and it does from the code source commits of OLM: https://github.com/operator-framework/operator-lifecycle-manager/commits/master

mac:~ jianzhang$ oc exec catalog-operator-86f77c9666-2c5nk -- olm --version
OLM version: 0.11.0
git commit: d2209c409b35f1db4669c474044decc6995f624d

We can also get the details by using `git show` under OLM git repo, as below:
mac:operator-lifecycle-manager jianzhang$ git show d2209c409b35f1db4669c474044decc6995f624d
commit d2209c409b35f1db4669c474044decc6995f624d (HEAD -> master, origin/master, origin/HEAD)
Merge: cd86d42b a624aaec
Author: OpenShift Merge Robot <openshift-merge-robot.github.com>
Date:   Fri Jul 26 23:04:36 2019 +0200

    Merge pull request #967 from tkashem/changelog
    
    (release) update changelog

mac:operator-lifecycle-manager jianzhang$ git branch
  fix-provider
* master

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:2922