Generate binaries only if there are changes in src code.

[NevilleC]

Changes I am making:

1. The target .gopathok was listed in .PHONY which looks wrong as it regenerates .gopathok every time we re-run it, which was a part of the issue make install should not make binaries if already exist #4367. I removed it to avoid that. If .gopathok is present', makefile should not need to rerun it.
2. Ensure the binaries are created only if they don't exist by renaming podman to bin/podman and podman-remote to bin/podman-remote.
3. Add a SOURCES = $(shell find . -name "*.go") and put it as a dependency of the podman binaries target. It allows us to re-generate the binaries only when there is a change in the source files. The downside is it increases the running time of the command that generates them (20 seconds on my virtual machine running Centos 7). If this is a problem, we could introduce a hidden file that would list all the files to track, that would need to be updated only when a dev is introducing new files.

We can now run make && sudo make install without error, so if this solution is accepted, I believe it should solve the issue listed here.

Closes #4367

Signed-off-by: NevilleC [email protected]

[openshift-ci-robot]

Hi @NevilleC. Thanks for your PR.

I'm waiting for a containers member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[NevilleC]

/retest

[openshift-ci-robot]

@NevilleC: Cannot trigger testing until a trusted user reviews the PR and leaves an /ok-to-test message.

In response to this:

/retest

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[rhatdan]

LGTM
@edsantiago @mheon PTAL

[rhatdan]

Thanks @NevilleC nice work.

[edsantiago]

I have a nagging memory that we've tried this before and it broke the specfile build. I can't find the relevant code or emails, and git blame wasn't helpful, and I have commitments soon that prevent me from pursuing right now. Commenting in case it rings a bell for someone else. It does look good, I just think we need to make sure it works with koji/brew.

[rhatdan]

/approve

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: NevilleC, rhatdan

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

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

[rhatdan]

@NevilleC could you make sure that the rpm spec file still works.

[rhatdan]

I think you should enable it in the build script.

[NevilleC]

/retest

[NevilleC]

it seems to be a temp issue in ci/prow/images

Error: Error downloading packages:
  Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=updates-released-f29&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org]
error: build error: running 'dnf install -y rpms/x86_64/*' failed with exit code 1

I will retry re-test one last time.

/retest

[edsantiago]

I'm sorry for causing so much churn and confusion: my comments referred to the real spec build, as in the one in fedpkg, not the fake spec in this repo. Since I still can't find anything relevant in the history, I vote to just approve this and then see if koji fails.

/retest

[edsantiago]

@rhatdan @cevich what is rdoproject.org/github-check?

[mheon]

Openstack TripleO gating tests

[mheon]

I think we're not expecting that to go green yet - @ssbarnea is that right?

[mheon]

For the record, I think we're good to merge once that's clarified.

[edsantiago]

Openstack TripleO gating tests

I phrased my question improperly - I should've asked, why are they failing, why is there no actual log (the link is useless), how does a regular user restart or waive that, and where is there documentation on this newly-randomly-added CI test?

[cevich]

Link is working for me now but page is tl;dr. This SNAFU reads like growing-pains to me, probably just need to wait for clarification. It would be up to the (other) CI system to set the status as ignored instead of failed. There's nothing in github directly that can set a non-native status to other that what was reported. The only option from a github POV is 'X is required for merge' (which is not currently set).

[edsantiago]

Link is working for me now

If you look closely you'll see that link is of the form .../long-identifier; whereas the page that loads is merely /status with no identifier. That suggests to me that the actual results page is 404, and the rdoproject site is redirecting that to a generic status page.

[cevich]

a generic status page

OIC, yes. it could also be that you need to be logged in to that site and/or have permissions see the actual status.

FWIW, this behavior is happening on all/many other PRs as well.

[mheon]

Given this, I'm going to say we see if it merges even with the check red.
/lgtm

[cevich]

all/many other PRs as well.

Meaning, the check fails. Looking now, the status-page thing does works on other PRs. Still, seems like growing-pains related issues overall.

[cevich]

merges even with the check red.

Yes, should be able to. AFAIK that check isn't marked as required in the repo. config.

[NevilleC]

thanks all for help and feedback!

[edsantiago]

Followup: rawhide build is fine, and so are gating tests. I'm not sure what I was (mis)remembering, but this clearly seems to be working. Thanks for your PR.

[NevilleC]

great, thanks for the testing @edsantiago