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

fix: update test #525

Merged
merged 4 commits into from
Sep 12, 2023
Merged

fix: update test #525

merged 4 commits into from
Sep 12, 2023

Conversation

maheshwarishikha
Copy link
Member

@maheshwarishikha maheshwarishikha commented Sep 5, 2023

Description

Updates test

Release required?

  • No release
  • Patch release (x.x.X)
  • Minor release (x.X.x)
  • Major release (X.x.x)
Release notes content

Run the pipeline

If the CI pipeline doesn't run when you create the PR, the PR requires a user with GitHub collaborators access to run the pipeline.

Run the CI pipeline when the PR is ready for review and you expect tests to pass. Add a comment to the PR with the following text:

/run pipeline

Checklist for reviewers

  • If relevant, a test for the change is included or updated with this PR.
  • If relevant, documentation for the change is included or updated with this PR.

Merge actions for mergers

  • When merging, use a relevant conventional commit message that is based on the PR contents and any release notes provided by the PR author. The commit message determines whether a new version of the module is needed, and if so, which semver increment to use (major, minor, or patch).
  • Merge by using "Squash and merge".

@maheshwarishikha
Copy link
Member Author

/run pipeline

@ocofaigh
Copy link
Member

ocofaigh commented Sep 5, 2023

@maheshwarishikha Did this test ever work? Wondering why all of a sudden we now need to add this import?

Also the test failed with this:
Error: [ERROR] Error creating authorization policy: The policy wasn't created because an access policy with identical attributes already exists. Please update the roles in the existing policy (30817f7e-a561-49ac-b01a-92f82fc4a45d), or update the one you're trying to assign to include a different attribute assignment.

This can happen due to the known limitation around scoping the auth policy. To get it to pass, you will have to do some cleanup on our account.

@rajatagarwal-ibm
Copy link
Member

rajatagarwal-ibm commented Sep 5, 2023

@maheshwarishikha we do not need this import as "testhelper" is already imported in the pr_test.go. Go lang shares imports at the same directory level.

@maheshwarishikha
Copy link
Member Author

@maheshwarishikha we do not need this import as "testhelper" is already imported in the pr_test.go. Go lang shares imports at the same directory level.

When I run local as below, I hit the same error.

% make run-tests-local RUN=TestRunBasicExample      
cd tests && go test -run TestRunBasicExample -count=1 -v -timeout 300m
# github.com/terraform-ibm-modules/terraform-ibm-landing-zone-vsi [github.com/terraform-ibm-modules/terraform-ibm-landing-zone-vsi.test]
./other_test.go:12:13: undefined: testhelper
FAIL	github.com/terraform-ibm-modules/terraform-ibm-landing-zone-vsi [build failed]
make: *** [run-tests-local] Error 1

And after importing that library, error is resolved.

@maheshwarishikha
Copy link
Member Author

/run pipeline

@rajatagarwal-ibm
Copy link
Member

@maheshwarishikha I do not encounter that error.

@ocofaigh
Copy link
Member

ocofaigh commented Sep 5, 2023

Maybe it is because you are explicitly running that test make run-tests-local RUN=TestRunBasicExample. Does it work if you just run make run-tests-local ?

@rajatagarwal
Copy link

@ocofaigh i ran exactly that same test

@ocofaigh
Copy link
Member

ocofaigh commented Sep 5, 2023

@rajatagarwal I wonder would it work if you cleared your go cache and re-ran?

@maheshwarishikha
Copy link
Member Author

Maybe it is because you are explicitly running that test make run-tests-local RUN=TestRunBasicExample. Does it work if you just run make run-tests-local ?

nopes...
it did not work for me either.

% make run-tests-local
cd tests && go test -run '' -count=1 -v -timeout 300m
# github.com/terraform-ibm-modules/terraform-ibm-landing-zone-vsi [github.com/terraform-ibm-modules/terraform-ibm-landing-zone-vsi.test]
./other_test.go:13:13: undefined: testhelper
FAIL	github.com/terraform-ibm-modules/terraform-ibm-landing-zone-vsi [build failed]
make: *** [run-tests-local] Error 1

Not sure, whats the difference between Rajat's and my m/c env.... 🤔

@maheshwarishikha
Copy link
Member Author

/run pipeline

1 similar comment
@maheshwarishikha
Copy link
Member Author

/run pipeline

@maheshwarishikha
Copy link
Member Author

@ocofaigh currently there is no existing policy in Dev account block storage -> HPCS but test is still failing with the error auth policy exists. Is it something related to upgrade test specifically? otherwise what else.... 🤔

@rajatagarwal-ibm
Copy link
Member

@ocofaigh Regardless if we have that import in both files it would fail with an "unused import" error.

4197 ± make run-tests-local                                                                                                                          ✹
cd tests && go test -run '' -count=1 -v -timeout 300m
# github.com/terraform-ibm-modules/terraform-ibm-landing-zone-vsi [github.com/terraform-ibm-modules/terraform-ibm-landing-zone-vsi.test]
./other_test.go:7:2: "github.com/terraform-ibm-modules/ibmcloud-terratest-wrapper/testhelper" imported and not used
FAIL    github.com/terraform-ibm-modules/terraform-ibm-landing-zone-vsi [build failed]
make: *** [run-tests-local] Error 1

@ocofaigh
Copy link
Member

ocofaigh commented Sep 6, 2023

@maheshwarishikha If the standard test and the upgrade test are trying to create the same auth policy, then yes we will face this issue. How about running one of the tests with key protect, and the other with hpcs so they don't clash?
We could update the example to handle both so we just need 1 example. but the tests trigger it differently

@maheshwarishikha
Copy link
Member Author

maheshwarishikha commented Sep 6, 2023

@ocofaigh Regardless if we have that import in both files it would fail with an "unused import" error.

4197 ± make run-tests-local                                                                                                                          ✹
cd tests && go test -run '' -count=1 -v -timeout 300m
# github.com/terraform-ibm-modules/terraform-ibm-landing-zone-vsi [github.com/terraform-ibm-modules/terraform-ibm-landing-zone-vsi.test]
./other_test.go:7:2: "github.com/terraform-ibm-modules/ibmcloud-terratest-wrapper/testhelper" imported and not used
FAIL    github.com/terraform-ibm-modules/terraform-ibm-landing-zone-vsi [build failed]
make: *** [run-tests-local] Error 1

Are you trying out with the latest code? Because the new code added in other_test.go uses testhelper library.

@ocofaigh
Copy link
Member

ocofaigh commented Sep 6, 2023

@maheshwarishikha I believe you are correct - I think this change is needed. Without it I get:

 % make run-tests-local RUN=TestRunBasicExample 
cd tests && go test -run TestRunBasicExample -count=1 -v -timeout 300m
# github.com/terraform-ibm-modules/terraform-ibm-landing-zone-vsi [github.com/terraform-ibm-modules/terraform-ibm-landing-zone-vsi.test]
./other_test.go:13:13: undefined: testhelper
FAIL	github.com/terraform-ibm-modules/terraform-ibm-landing-zone-vsi [build failed]
make: *** [run-tests-local] Error 1

@maheshwarishikha
Copy link
Member Author

@maheshwarishikha If the standard test and the upgrade test are trying to create the same auth policy, then yes we will face this issue. How about running one of the tests with key protect, and the other with hpcs so they don't clash? We could update the example to handle both so we just need 1 example. but the tests trigger it differently

hmm..yes, that could be the reason. I'll check tests.

@maheshwarishikha
Copy link
Member Author

maheshwarishikha commented Sep 11, 2023

@ocofaigh
I think example will handle any KMS. So as such no update required for example. One test can be configured with HPCS and another one with KMS. Will test it.

Got one question - Dont we use existing KP instance for any test? If yes, where are the details of KP instance stored? I do not find KP details at common-dev-assets/common-go-assets/common-permanent-resources.yaml

There is one instance geretain-keyprotect under geretain-vincent rg. Should we use that or create a new geretain instance?

@maheshwarishikha
Copy link
Member Author

/run pipeline

@maheshwarishikha
Copy link
Member Author

@ocofaigh I think example will handle any KMS. So as such no update required for example. One test can be configured with HPCS and another one with KMS. Will test it.

Got one question - Dont we use existing KP instance for any test? If yes, where are the details of KP instance stored? I do not find KP details at common-dev-assets/common-go-assets/common-permanent-resources.yaml

There is one instance geretain-keyprotect under geretain-vincent rg. Should we use that or create a new geretain instance?

  1. It is confirmed that PR tests were failing because of parallel execution. I just commented t.parallel to be sure for the problem, and the pipeline tests passed.
  2. Regarding KP instance, confirmed with Daniel that we do not have any permanent KP instance to use and it is easy to create and use.
  3. If we plan to run one test with HPCS and one with KP, then we need to modify example in such a way that
! kp_exists => create KP, rings get crn and run test

Alternate way is ...we can run tests sequentially instead of making example complex. This is what I tried and worked.

Let me know your thoughts on this. Thanks

@ocofaigh
Copy link
Member

@maheshwarishikha We don't have a permanent Key Protect instance. We just create one in the examples. That way we always have a unique instance ID and full end to end examples. This also mans Key Protect auth policies won't clash since its a unique instance every time

@ocofaigh
Copy link
Member

So can we have the standard test using HPCS and the upgrade test using Key Protect? That way there won't be any clashes

@maheshwarishikha
Copy link
Member Author

So can we have the standard test using HPCS and the upgrade test using Key Protect? That way there won't be any clashes

It can be done. In this case, the example needs modification such that it will create KP instance, auth policy, keys etc if kms_does_not_exist already.

On a lighter note, how much it helps if we do this additional work in example just for PR test? why not to run test sequentially that also takes care of this clash policy issue?

@ocofaigh
Copy link
Member

@maheshwarishikha I'm going to merge this to unblock the pipeline, however I still think we should re-work the example so it can be run in parallel. Otherwise it takes twice as long for pipeline to run tests

@ocofaigh ocofaigh merged commit 9ee8fe7 into main Sep 12, 2023
@ocofaigh ocofaigh deleted the sm-5739 branch September 12, 2023 18:31
@terraform-ibm-modules-ops
Copy link
Contributor

🎉 This PR is included in version 2.7.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants