fix: change podspec template serviceAccount enable and name handling

[nakarin-s]

No description provided.

[gemini-code-assist]

Summary of Changes

Hello @nakarin-s, I'm Gemini Code Assist¹! 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 refines the Helm chart's common pod specification template to enhance the handling of Kubernetes service account configuration. The changes introduce more explicit control over whether a service account is created and how its name is specified, improving flexibility and robustness in deployment configurations.

Highlights

• Service Account Configuration: The logic for configuring the serviceAccountName in the pod specification has been updated to use a more granular approach. Instead of checking for the existence of a single serviceAccount value, it now explicitly checks for .Values.serviceAccount.create to determine if a service account should be enabled.
• Service Account Naming: The serviceAccountName is now derived from .Values.serviceAccount.name and is explicitly quoted using the quote function, ensuring proper string handling for Kubernetes resource names.

🧠 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 Assist

The 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 /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

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 .gemini/ folder in the base of the repository. Detailed instructions can be found here.

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

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request fixes how the service account is handled in the pod spec template. The change correctly uses a boolean flag to enable the service account and specifies the name. However, it introduces an inconsistency: if a service account name is not provided, the pod spec will not use the default name that the service account resource is created with. My review includes a critical comment to address this by using the same default name logic in both places, ensuring the pod is associated with the correct service account.

[gemini-code-assist]

There's an inconsistency in how the service account name is determined. Here, serviceAccountName is set to .Values.serviceAccount.name. However, in charts/common/templates/_serviceaccount.yaml, the service account resource is created with a default name (include "onechart.fullname" .) if .Values.serviceAccount.name is not provided.

If serviceAccount.create is true but serviceAccount.name is empty, a new service account will be created with a generated name, but the pod will be configured to use an empty-named service account, which will fall back to the default service account in the namespace. This will cause the pod to not use the service account created for it.

To ensure the pod uses the correct service account, the logic for determining the name should be consistent. You should use the same default value here.

serviceAccountName: {{ .Values.serviceAccount.name | default (include "onechart.fullname" .) | quote }}