-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Use a project pool to avoid test collisions #1428
Comments
We're using individual tests for Node.js instead of one group test as it's much easier to see on the dashboard which tests are newly failing. If they're all grouped together, chances are that there's always a red one and nobody notices new failures (speaking from experience 😞 ). |
I think the way for now is to use precise names in tests and clean up test specific resources. Closing this for now. Feel free to re-open if we proceed to work on this. |
The golang and ruby sample repositories use a project pool to provide a dedicated GCP project for every CI run.
Doing this is extremely useful for any tests which consume GCP resources:
Obstacles: Based on my understanding of how the gimmeproj mechanism works, this would be done for discrete CI runs. This means it would need to apply on a per sample basis in Node.js unless some more grouping were done at the Kokoro configuration level.
I am raising this because navigation of service name uniqueness for Cloud Run samples has taken a significant amount of time.
Ruby and Golang facilitate this with the gimmeproj tool
@broady
The text was updated successfully, but these errors were encountered: