RFC: Introduce PodmanTestIntegration.PodmanCleanly

[mtrmac]

This significantly simplifies the ceromony of running a Podman command in integration tests, from

  session := p.Podman([]string{"stop", id})
  session.WaitWithDefaultTimeout()
  Expect(session).Should(ExitCleanly())

to

  p.PodmanCleanly("stop", id)

There are >4650 instances of ExitCleanly() in the tests, and many could be migrated; this does not do that.

@containers/podman-maintainers RFC. While writing integration tests, I find the ever-present repetitive boilerplate hard to read/maintain, and generally off-putting; OTOH the PodmanCleanly call does not show explicitly that any testing is happening. I’m also, short-term, not able to migrate everything, so introducing this would make tests less consistent for now.

It’s also very possible there’s already a much better way to do things, and I just don’t know.

Does this PR introduce a user-facing change?

None

[mtrmac]

I’m also 100% open to suggestions of a better name of the helper.

[rhatdan]

I think PodmanExitCleanly() would be a better name.
But this is a good idea.
LGTM

[giuseppe]

LGTM, we can incrementally move new tests to the new function.

I also think PodmanExitCleanly is a bit more descriptive

[Luap99]

I also prefer PodmanExitCleanly as name. Otherwise I think this is a good idea and I don't see a strict need to manually convert all callers right now.
We can start using it for new code only.

[Luap99]

This should use ExpectWithOffset(1,...), the last line in the stack trace in the log will otherwise all point to this line here which is pretty pointless as I like to get linked to the actual command that failed.

[mtrmac]

Trying GinkgoHelper — that should also affect the failures in WaitWithDefaultTimeout.

[Luap99]

Ah yes that seems much better than having to deal with correct offset numbers.

[mheon]

I like it. LGTM once the comment from @Luap99 is addressed.
I would like to see an existing file migrated (one of the smaller ones) to see what this looks like in practice, but see no need to do this in this PR.

[baude]

what do people think about the inverse as well? PodmanExitFailure which takes a command and an exit code?

[baude]

I like it. LGTM once the comment from @Luap99 is addressed. I would like to see an existing file migrated (one of the smaller ones) to see what this looks like in practice, but see no need to do this in this PR.

If @mtrmac repushes, I can rebase and use in the artifact e2e tests happily.

[Luap99]

what do people think about the inverse as well? PodmanExitFailure which takes a command and an exit code?

It would need to take an error message as well (exit code checks are useless without proper error message checks) and then at that point the lines gets so long that it needs to be split on multiple lines anyway so then it is no longer that much shorter. Although I guess getting rid of the WaitWithDefaultTimeout() timeout calls would help a fair bit still

[mtrmac]

Updated:

• Renamed to PodmanExitCleanly
• Updated attach_test.go to show what this looks like (notably how the PodmanExitCleanly calls look a bit different from raw Podman calls when we expect failure or want some extra processing).
• Marked the new utility as a helper.

---

It seems to me that the command tests might be possible to express in some more concise way with a builder-like API:

/* session = */ p.Podman("system", "reset", "-f") // default: run command, default timeout, expect success

/* session = */ p.Command("skopeo", "--version") // other command, default timeout, expect success

/* session = */ p.PodmanWithOptions("other", "situations").Options(
    WithTimeout(other),
    ExpectError(code, string),
    DoNotExecute(), // for truly custom situations
    NoEvents(), // instead of the PodmanBase / Podman split
    …
)

but, also, we are not in the business of inventing a new integration test DSL. There’s a balance to be struck; the sweet spot is probably being a bit more expressive / capable than just PodmanExitCleanly (for non-Podman commands and common error situations?), but not much more expressive, adding dozens of new helpers.

If nothing else, I think that using ...string instead of having []string{} on every call site is an obvious improvement that could happen in more situations.

Anyway, this is not something I can work on right now. I just wanted to avoid the very obvious boilerplate when writing a few hundred lines of new tests.

[Luap99]

LGTM

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: giuseppe, Luap99, mtrmac

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 [Luap99,giuseppe,mtrmac]

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

[rhatdan]

/lgtm