Kustomize build CI + Kustomize docs + ServiceAccounts variation
#1097
Conversation
|
🚲 PR staged at http://35.223.150.213 |
|
🚲 PR staged at http://35.223.150.213 |
|
🚲 PR staged at http://35.223.150.213 |
|
🚲 PR staged at http://35.223.150.213 |
|
🚲 PR staged at http://35.223.150.213 |
|
🚲 PR staged at http://35.223.150.213 |
|
🚲 PR staged at http://35.223.150.213 |
|
🚲 PR staged at http://35.223.150.213 |
| - name: kustomize build memorystore | ||
| run: | | ||
| cd kustomize/ | ||
| kustomize edit add component components/memorystore |
There was a problem hiding this comment.
Question:
Each step is adding a Component and then running Kustomize-building.
My question: Is each step building on top of the previous step?
For instance, does the kustomize build google-cloud-operations step include the cymbal-branding Component?
Reason I ask: I would rather not build steps on top of the previous step. I think we should test each Component on its own. I think promising users that all the Components ALL components will work together is a big commitment. I think the CUJ we should 100% support and prioritize is "each Component can be deployed on its own".
There was a problem hiding this comment.
Ah ah, you just read my mind and my screen actually! Aligned with you, 100% agreed on that.
I will work on the draft mode to include this:
- Do not repeat the steps, but have a loop in bash browsing the subfolders in
components- with that, as soon as a new component is added, no need to update the CI definition - Each test will be done alone, just 1 component at a time
- The last test will combined all the components, to have kind of a "test them all"
There was a problem hiding this comment.
Done! Let me know what you think! ;)
|
🚲 PR staged at http://35.223.150.213 |
|
🚲 PR staged at http://35.223.150.213 |
|
🚲 PR staged at http://35.223.150.213 |
|
🚲 PR staged at http://35.223.150.213 |
|
🚲 PR staged at http://35.223.150.213 |
|
🚲 PR staged at http://35.223.150.213 |
|
🚲 PR staged at http://35.223.150.213 |
1 similar comment
|
🚲 PR staged at http://35.223.150.213 |
|
🚲 PR staged at http://35.223.150.213 |
There was a problem hiding this comment.
Thank you so much, @mathieu-benoit, for these improvements.
I also highly appreciate that you configured the new Kustomize-related CI to only run if changes are made to /kustomize or .github/workflows/kustomize-build-ci.yaml.
I had a lot of nitpicks from my end — so I've gone ahead and committed them myself to avoid back-and-forth and to avoid wasting your time. 😄
Of course, please create smaller, more focused pull-requests in the future. 🙏
E.g., this pull-request could've been 3 (as suggested by the title).
It would really help me as a reviewer. 😊
I approve these changes!
Feel free to merge and/or undo any change(s) I made.
Once again, thank you!!! 🚀
) * Create kustomize-build-ci.yml * Update ci-pr.yaml * add license header * kustomize build cymbal-branding * Update kustomize-build-ci.yml * Update kustomize-build-ci.yml * Just one file for the Kustomize base (equivalent of release/) * update the release script/process to copy the file from release/ to kustomize/base * kubectl kustomize * components/network-policy * do not trigger ci-main for kustomize/ updates * rename ci file for consistency * test each component at first then eventually test all-in-one * Update Kustomize for Memorystore to take into account more generic REDIS_ADDR * kustomize build custom cuj instead of a generic all-in-one * fix ci * rename network-policy by network-policies under kustomize/ * Review Kustomize main doc * update Kustomize main doc * fix broken links * Update Kustomize docs with consistency * Formatting the kustomization.yaml files like kustomize create/edit do * Add ServiceAccounts via Kustomize * fix file path * Update README.md * Update kustomize/README.md * Update headings in /kustomize/README.md * Updae kustomize/ docs * End ServiceAccounts with newline for cleaner cat * Avoid use of Google-centric term, CUJ * Update terraform/README.md Co-authored-by: Nim Jayawardena <nimjay@google.com>
…ogleCloudPlatform#1097) * Create kustomize-build-ci.yml * Update ci-pr.yaml * add license header * kustomize build cymbal-branding * Update kustomize-build-ci.yml * Update kustomize-build-ci.yml * Just one file for the Kustomize base (equivalent of release/) * update the release script/process to copy the file from release/ to kustomize/base * kubectl kustomize * components/network-policy * do not trigger ci-main for kustomize/ updates * rename ci file for consistency * test each component at first then eventually test all-in-one * Update Kustomize for Memorystore to take into account more generic REDIS_ADDR * kustomize build custom cuj instead of a generic all-in-one * fix ci * rename network-policy by network-policies under kustomize/ * Review Kustomize main doc * update Kustomize main doc * fix broken links * Update Kustomize docs with consistency * Formatting the kustomization.yaml files like kustomize create/edit do * Add ServiceAccounts via Kustomize * fix file path * Update README.md * Update kustomize/README.md * Update headings in /kustomize/README.md * Updae kustomize/ docs * End ServiceAccounts with newline for cleaner cat * Avoid use of Google-centric term, CUJ * Update terraform/README.md Co-authored-by: Nim Jayawardena <nimjay@google.com>
kustomize/folder - Same approach as Add a small Terraform CI #1096 but for Kustomizekustomization.yamlfile inkustomize/kustomize/componentsbaseand somecomponentsmainif files are updated inkustomize/folder to avoid charging theself-hostedrunner as well as avoid building/deploying the containers, all of that not related to the Kustomize implementation in this repo as of nowkubernetes-manifests.yamlinkustomize/basefolder, like inrelease/release/kubernetes-manifests.yamlfile inkustomize/base/kubernetes-manifests.yamlREDIS_ADDRvalue update for the Memorystore component (a Redis instance could have a port after the IP and it could also be a DNS instead of IP). Here, I'm proposing that any Kustomize component which needs to have value injection (sed) in their Kustomize component file is surrounded by{{...}}, in this case{{REDIS_ADDR}}. That's the only component for now having this, so that's kind of a token convention for future components which will need that in the future.ServiceAccountsvariation via Kustomize