Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Makefile: Handle unexpected empty var. values #14435

Merged
merged 1 commit into from
Jun 2, 2022

Conversation

cevich
Copy link
Member

@cevich cevich commented May 31, 2022

Fixes #14021

Substitution values built from $(shell ...) output can easily be empty
due to the shell's default pipefail behavior. This can also hide
non-zero exit codes, similarly resulting in empty values being set.
While not a perfect fix, the situation is improved by using the
err_if_empty function in all cases where empty values would be
unexpected. Also remove the definitions for GIT_BRANCH and
GIT_BRANCH_CLEAN which don't seem to actually be used anywhere
(including in code).

Does this PR introduce a user-facing change?

None

@cevich cevich requested review from edsantiago and mheon May 31, 2022 15:56
@openshift-ci openshift-ci bot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. release-note-none labels May 31, 2022
Makefile Outdated Show resolved Hide resolved
@cevich cevich force-pushed the makefile_empty branch 2 times, most recently from 4f8b00b to 593df42 Compare June 1, 2022 20:16
contrib/cirrus/runner.sh Outdated Show resolved Hide resolved
Fixes containers#14021

Substitution values built from `$(shell ...)` output can easily be empty
due to the shell's default `pipefail` behavior.  This can also hide
non-zero exit codes, similarly resulting in empty values being set.
While not a perfect fix, the situation is improved by using the
`err_if_empty` function in all cases where empty values would be
unexpected.  Remove the definitions for `GIT_BRANCH` and
`GIT_BRANCH_CLEAN` which don't seem to actually be used anywhere
(including in code).

Add a simple release-test to verify `podman info` outputs a non-empty
value for "GitCommit".

Signed-off-by: Chris Evich <[email protected]>
@cevich cevich marked this pull request as ready for review June 2, 2022 15:29
@cevich cevich changed the title [WIP] Makefile: Handle unexpected empty var. values Makefile: Handle unexpected empty var. values Jun 2, 2022
@openshift-ci openshift-ci bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jun 2, 2022
@cevich
Copy link
Member Author

cevich commented Jun 2, 2022

Final review-note: I'm a little nervous about build-targets used outside of CI. I did not check/test any of them 😨

Copy link
Member

@edsantiago edsantiago left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This whole thing makes me super uncomfortable. I don't understand its ramifications. I don't understand why only some vars get the err_if_empty treatment.

I did run make with my .git subdirectory renamed, and confirmed that it still builds; but I don't know what else to test. I'd like to see the scope of this PR reduced to a reasonably small bare minimum, then give it a month or two (including releases and bodhi builds) before getting aggressive with TMPDIR and GOOS and _HLP_whatever. But that's just a preference, and I won't block because of it.

DATE_FMT = %s
ifdef SOURCE_DATE_EPOCH
BUILD_INFO ?= $(shell date -u -d "@$(SOURCE_DATE_EPOCH)" "+$(DATE_FMT)" 2>/dev/null || date -u -r "$(SOURCE_DATE_EPOCH)" "+$(DATE_FMT)" 2>/dev/null || date -u "+$(DATE_FMT)")
BUILD_INFO ?= $(shell date -u -d "@$(call err_if_empty,SOURCE_DATE_EPOCH)" "+$(DATE_FMT)" 2>/dev/null || date -u -r "$(SOURCE_DATE_EPOCH)" "+$(DATE_FMT)" 2>/dev/null || date -u "+$(DATE_FMT)")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given the ifdef just above, isn't this change unnecessary (and hence misleading)?

Comment on lines +91 to +92
$(if $(GIT_COMMIT),-X $(LIBPOD)/define.gitCommit=$(GIT_COMMIT),) \
$(if $(BUILD_INFO),-X $(LIBPOD)/define.buildInfo=$(BUILD_INFO),) \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Empty define.X= seems harmless, and has been working for many years, and is actually pretty clean and easy to read... so I'd be inclined to just revert this change, leaving it as it was

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, thanks. I was unsure of it as well.

Comment on lines +680 to +681
$(MAKE) podman-v$(call err_if_empty,RELEASE_NUMBER).msi
podman-v%.msi: test/version/version podman-remote-windows podman-remote-windows-docs podman-winpath win-sshproxy
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no way to review Windows code. @n1hility are you our Windows expert? Could you bless this?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure looks fine, will test

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

everything passes

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW: We do actually publish the latest test-builds of this MSI (among other binaries). It's available from https://api.cirrus-ci.com/v1/artifact/github/containers/podman/artifacts/binary/podman-<version>.msi Currently <version> is v4.2.0-dev. Though the build is out of date due to a problem I'm working on fixing elsewhere.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah thanks! good to know

@cevich
Copy link
Member Author

cevich commented Jun 2, 2022

I don't understand why only some vars get the err_if_empty treatment.

Oh, that's simple to answer, it relates to #14021. We only need to check cases where a shell call may have a component exit non-zero and return an (otherwise) unexpected empty value. For example if when pipes are used (since pipefail is not set). Though to keep things simple, I tried to stick the check on anything based on a shell call.

I'd like to see the scope of this PR reduced to a reasonably small bare minimum

I'm not sure how to do both that, and fix #14021 😞

@edsantiago
Copy link
Member

Ok then. Fingers crossed, then.

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Jun 2, 2022
@rhatdan
Copy link
Member

rhatdan commented Jun 2, 2022

/approve

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Jun 2, 2022

[APPROVALNOTIFIER] This PR is APPROVED

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

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

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jun 2, 2022
@openshift-merge-robot openshift-merge-robot merged commit 2777ecd into containers:main Jun 2, 2022
@cevich
Copy link
Member Author

cevich commented Jun 3, 2022

Ok then. Fingers crossed, then.

Aye 😞 sometimes that's all there is to do. But a fix could be one revert away 😁 Thanks for reviewing, I do appreciate it.

@cevich cevich deleted the makefile_empty branch April 18, 2023 14:45
@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Aug 31, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 31, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. release-note-none
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Automation] Makefile can give false-positive exit status
6 participants