-
Notifications
You must be signed in to change notification settings - Fork 51
feat(e2e): skip SSM repository deletion and improve creation logging #2002
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
base: main
Are you sure you want to change the base?
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
Summary of ChangesHello @cowsking, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses flaky end-to-end test failures caused by repository name collisions when tests run in parallel. By incorporating a unique identifier into the SSM repository naming logic, each test case can now create and interact with its own distinct repository, ensuring isolation and stability in shared testing environments. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request aims to prevent repository name collisions in parallel E2E tests by adding a uniqueID to SSM repository names. While the goal is valid, the implementation has a critical issue: the signature change in newSSMClient is not reflected in its calling code, which will lead to a compilation failure. Additionally, the method for appending the uniqueID can result in repository names that violate GCP's length constraints. I've provided comments with suggestions to fix these issues.
|
|
||
| // newSSMClient instantiates a new SSM client. | ||
| func newSSMClient(repoPrefix string, shell *testshell.TestShell, projectNumber string) *SSMClient { | ||
| func newSSMClient(repoPrefix string, shell *testshell.TestShell, projectNumber string, uniqueID string) *SSMClient { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The signature of newSSMClient has been changed to accept a uniqueID, but the call site in e2e/nomostest/gitproviders/git-provider.go has not been updated to pass this new argument. This will result in a compilation error. Please update the call to newSSMClient in NewGitProvider and thread the uniqueID through as needed.
| full := util.SanitizeGCPRepoName(c.repoPrefix, name) | ||
| if c.uniqueID != "" { | ||
| full = fmt.Sprintf("%s-%s", full, c.uniqueID) | ||
| } | ||
| return full |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The current implementation appends uniqueID after the repository name has been sanitized by util.SanitizeGCPRepoName. This can lead to repository names that exceed GCP's maximum length limit (63 characters), as the sanitization function's length check is bypassed. To ensure the final name is always valid, the uniqueID should be incorporated into the name before sanitization.
| full := util.SanitizeGCPRepoName(c.repoPrefix, name) | |
| if c.uniqueID != "" { | |
| full = fmt.Sprintf("%s-%s", full, c.uniqueID) | |
| } | |
| return full | |
| if c.uniqueID != "" { | |
| name = fmt.Sprintf("%s-%s", name, c.uniqueID) | |
| } | |
| return util.SanitizeGCPRepoName(c.repoPrefix, name) |
|
|
||
| // NewGitProvider creates a GitProvider for the specific provider type. | ||
| func NewGitProvider(t testing.NTB, provider, clusterName string, logger *testlogger.TestLogger, shell *testshell.TestShell) GitProvider { | ||
| func NewGitProvider(t testing.NTB, provider, clusterName string, logger *testlogger.TestLogger, shell *testshell.TestShell, uniqueID string) GitProvider { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you confirm how 'repo ID collision' was the root cause of the flakiness?
Since tests run sequentially on a given cluster, reusing the repository (as originally designed) should be safe.
| // DeleteObsoleteRepos is a no-op because SSM repo names are determined by the | ||
| // test cluster name and RSync namespace and name, so it can be reused if it | ||
| // failed to be deleted after the test. | ||
| // DeleteObsoleteRepos is a no-op because SSM repo names are unique per test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we generate unique repositories for every test run, leaving this as a no-op will cause repositories to accumulate indefinitely - we should implement the actual deletion logic here to prevent resource exhaustion. In the original design the repository gets reused between tests so the delete can be a no-op.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. just spoke with Camila, and I might try modifying the deletion process in SSM first to see if it works.
DeleteRepositoriesa no-op for the SSM provider, as repository names are derived from the cluster and RSync names and can be reused.CreateRepositoryto log an info message instead of returning an error if thegcloud describecommand fails with an error other thanNOT_FOUND.