Nothing Special   »   [go: up one dir, main page]

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

Update TestNormalize to only test Windows platform #6569

Merged
merged 1 commit into from
Mar 11, 2022

Conversation

estesp
Copy link
Member
@estesp estesp commented Feb 18, 2022

The output of platforms.DefaultSpec() and the normalized version of the
default platform on 32- and 64-bit ARM are not comparable. This test
was added to validate not losing Windows-specific information during
normalize of the platform object, so for now we are moving this to be a
Windows-only test until we resolve the right behavior on ARM.

I noticed that tests on ARM64 were failing and found that #6497 added this
test; I also verified in the openlab test logs this is the new failure.

// cc: @thaJeztah

Signed-off-by: Phil Estes estesp@amazon.com

@estesp estesp added the cherry-pick/1.6.x Change to be cherry picked to release/1.6 branch label Feb 18, 2022
@@ -367,5 +367,13 @@ func TestParseSelectorInvalid(t *testing.T) {
}

func TestNormalize(t *testing.T) {
require.Equal(t, DefaultSpec(), Normalize(DefaultSpec()))
spec := DefaultSpec()
Copy link
Member

Choose a reason for hiding this comment

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

How about hard-coding the spec here instead of using DefaultSpec? Changing TestNormalize() based on the underlying architecture doesn't make much sense.

Copy link
Member Author

Choose a reason for hiding this comment

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

I guess maybe we should step back and understand what this is expected to test; seems from the origin PR this is about making sure we aren't losing the info for Windows platform objects on normalization. One option could be to just add this test for Windows and not other platforms? @thaJeztah ?

Copy link
Member

Choose a reason for hiding this comment

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

Right, so @tonistiigi mentioned it was broken on ARM #6497 (comment), and I recall trying to make the test work in CI in this repo, but it depends on actual ARM hardware to do so (not GOOS/GOARCH) to get the processor architecture.

So indeed, what to test? I guess we should have a test to verify that OSVersion (and OSFeatures) are not dropped

But, the main issue may be that DefaultSpec() should (probably) call Normalize() (?) after all, if the DefaultSpec() is not normalised, that's a bit odd 🤔

Copy link
Member Author

Choose a reason for hiding this comment

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

I think this is a bit of a thorny area to unwind. It looks like a lot of the matcher logic does normalize passed in platform specs, but DefaultSpec() is usually used to initialize the exact tuple from client code (mostly only matters on architectures with variants, which leaves it in the realm of ARM/ARM64 at the moment).

I think we would need some analysis of all the call paths that use DefaultSpec() today to see whether losing or gaining the "vX" variant detail (depending on ARM variant/arch) would impact current expectations.

Maybe for now this test should just be a Windows test to validate we aren't losing the os.* content that was being lost prior to the PR fix which also added this test? wdyt?

@theopenlab-ci
Copy link
theopenlab-ci bot commented Feb 18, 2022

Build succeeded.

The output of platforms.DefaultSpec() and the normalized version of the
default platform on 32- and 64-bit ARM are not comparable. This test
was added to validate not losing Windows-specific information during
normalize of the platform object, so for now we are moving this to be a
Windows-only test until we resolve the right behavior on ARM.

Signed-off-by: Phil Estes <estesp@amazon.com>
@estesp estesp force-pushed the fix-normalize-test branch from b3bab52 to 807ded4 Compare March 10, 2022 16:39
@estesp estesp changed the title Update TestNormalize to handle ARM Update TestNormalize to only test Windows platform Mar 10, 2022
@@ -0,0 +1,27 @@
/*
Copy link
Contributor

Choose a reason for hiding this comment

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

Since its _test.go do we need a build directive here for windows? Or is the test tool smart enough now for *_windows_test.go to maintain the platform?

@@ -0,0 +1,27 @@
/*
Copy link
Contributor

Choose a reason for hiding this comment

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

Since its _test.go do we need a build directive here for windows? Or is the test tool smart enough now for *_windows_test.go to maintain the platform?

Copy link
Member Author

Choose a reason for hiding this comment

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

It's Go magic just like the files without _test.go; noticed that we actually need to remove directives from some files as it is duplication when the filename already provides the necessary platform directive.

Copy link
Contributor

Choose a reason for hiding this comment

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

Cool. I did not know that for _test files. Thanks!

Copy link
Member Author

Choose a reason for hiding this comment

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

From Go cmd/go build constraints documentation:

If a file's name, after stripping the extension and a possible _test suffix, matches any of the following patterns:

*_GOOS
*_GOARCH
*_GOOS_GOARCH

(example: source_windows_amd64.go) where GOOS and GOARCH represent any known operating system and architecture values respectively, then the file is considered to have an implicit build constraint requiring those terms (in addition to any explicit constraints in the file).

Copy link
Contributor

Choose a reason for hiding this comment

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

And people say golang isn't a systems language :). Super cool

@theopenlab-ci
Copy link
theopenlab-ci bot commented Mar 10, 2022

Build succeeded.

Copy link
Member
@mikebrow mikebrow left a comment

Choose a reason for hiding this comment

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

LGTM

@kzys kzys merged commit aa45f8e into containerd:main Mar 11, 2022
@thaJeztah
Copy link
Member

oh! forgot about this one

post-merge LGTM, thanks!

@estesp estesp deleted the fix-normalize-test branch March 12, 2022 15:04
@estesp estesp added cherry-picked/1.6.x PR commits are cherry-picked into release/1.6 branch and removed cherry-pick/1.6.x Change to be cherry picked to release/1.6 branch labels Mar 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cherry-picked/1.6.x PR commits are cherry-picked into release/1.6 branch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants