imagebuildah: if user sets --jobs=0 they expect no parallelism

[flouthoc]

Lot of users and tests set --jobs=0 they are expecting no parallelism
between stages but we still end up running builds in parallel for
multi-arch builds which indirectly executes stages in parallel since builds are parallel.

Example tests like https://github.com/containers/buildah/blob/main/tests/bud.bats#L3609 set --jobs=0 but they still execute build for similar name but different arch in parallel.

[Note:] This PR does not fix more that one race condition which is seen when multi-arch builds are performed without --jobs=0 as documented here: #3710 (comment) but it should fix flakes in CI as reported here: #3710

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: flouthoc

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

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

[flouthoc]

This should fix the flake as tests in CI use --jobs=0 but this does not means that actual race is fixed which can be seen again without --jobs=0 for multi-arch builds.

[nalind]

Lot of users and tests set --jobs=0 they are expecting no parallelism between stages but we still end up running builds in parallel for multi-arch builds which indirectly executes stages in parallel since builds are parallel.

Example tests like https://github.com/containers/buildah/blob/main/tests/bud.bats#L3609 set --jobs=0 but they still execute build for similar name but different arch in parallel.

That's why that test specifies --jobs=0. The default is to behave as though --jobs=1 was specified.

[flouthoc]

@nalind If I inferred it correctly --jobs=0 should mean no parallelism at all but we still do builds for each platform in parallel manner.

[nalind]

The intent of that test is definitely maximum parallelization.

[flouthoc]

@nalind Oh i see but then I think users have no way to serialize mult-arch builds.

[cevich]

users have no way to serialize mult-arch builds.

I think it's incorrect to equate serialized builds with serialized pulls, one doesn't necessarily imply the other. Though I appreciate it vastly complicates the fix. As a user doing an operation requiring a multi-arch pull, I expect that pull to happen as fast as my bandwidth allows - meaning in parallel when possible.

[nalind]

@nalind Oh i see but then I think users have no way to serialize mult-arch builds.

That's the default, and what happens with --jobs=1.

[flouthoc]

users have no way to serialize mult-arch builds.

I think it's incorrect to equate serialized builds with serialized pulls, one doesn't necessarily imply the other. Though I appreciate it vastly complicates the fix. As a user doing an operation requiring a multi-arch pull, I expect that pull to happen as fast as my bandwidth allows - meaning in parallel when possible.

@cevich Pulls are not causing the issue but i think builds are causing the issue, its easily reproduce-able when you run bud-multiple-platform-no-run a few times.

I'm going to close this PR since it is not doing what i expected it to do.