-
Notifications
You must be signed in to change notification settings - Fork 3
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
Template Subfolder convention #171
Conversation
- name: 'wif_provider' | ||
desc: 'Workload Identity Federation Provider (ex: projects/[project_id]/locations/global/workloadIdentityPools/[WIF_pool_name]/providers/[provider_name])' | ||
default: '' |
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 dunno about this, template rendering will "succeed" but produce broken GH workflows.
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.
When we added the workflows, now inputs for these are required for this template to render.
I think eventually extracting out the workflows/Dockerfiles as discussed in go/vendor-abcxyz-apps is the best move.
But for now, this is blocking the template from being able to be rendered locally, without the workflows. The env file just looks like:
AUTOMATION_SERVICE_ACCOUNT=
WIF_PROVIDER=
AR_REPOSITORY=
AR_LOCATION=
CR_SERVICE=
REGION=
PROJECT_ID=
with the default blanks. Maybe I can change the defaults to comments of the value hints in the desc for each input?
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 think this is a design problem that we can't just hack around this way. If we're going to include the workflows in the template, we should try hard to make them work. So I think we should either not have defaults or factor out the GH workflows.
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.
Ok, then I think maybe I'll prioritize factoring them out first before continuing with this PR. What do you think?
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.
That sounds fine to me
Also, if this is too large to review, I can split this up into smaller PRs, one for updating each template. |
Refactoring for rest_server: #180 |
Fix rest_server slog errors from #157. Can merge to https://github.com/abcxyz/abc/tree/kevya/template-subfolder first or main if #171 merges first.
Fix rest_server slog errors from #157. Can merge to https://github.com/abcxyz/abc/tree/kevya/template-subfolder first or main if #171 merges first.
Addresses #166 for existing templates in t folder.
Template files to be included are in a folder named "contents" (other options considered were "template", "render", "target", "src", "include")
Updates spec.yaml includes, usage example README, separates READMEs for each template.
Also adds some default blank values for template inputs to ensure render works according to the READMEs.