Vendor in containers/buildah v1.14.3

[rhatdan]

Signed-off-by: Daniel J Walsh [email protected]

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: 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]

Need this for podman 1.8.2 release.
@mheon @TomSweeneyRedHat @QiWang19 @baude @giuseppe @vrothberg PTAL

[rhatdan]

@edsantiago podman info should never show a -dev branch for Buildah.

[mheon]

LGTM

[edsantiago]

@edsantiago podman info should never show a -dev branch for Buildah.

I'm missing some context here. I recall discussing this a few weeks ago, in the context of a released podman should never show -dev. The implication I see in the above is that no podman ever should show -dev, is that correct? If the latter is correct, that should be easy to test, and I can write a hook for it. For the former, the conversation stalled because I was not aware of a reliable way to identify "this tag/build/pr is intended for release". @cevich is currently doing some promising work along those lines, though.

If my "no podman ever" interpretation is the right one, please let me know and I will add a CI test that blocks -dev in any committed buildah in any PR.

[TomSweeneyRedHat]

LGTM once tests are happy.
@edsantiago We should keep "buildah*-dev" out of a final Podman release, but I think it's OK on a rare occasion for upstream and even RC releases. Just hope we don't slip up an let one slip through tp a final though.

[rhatdan]

@edsantiago No this is the discussion we had a few weeks ago, wanted to make sure rc1 was failing your release testing.

[baude]

/lgtm