Douglas Chimento
67df3235ea
**Description** Fixes https://github.com/truecharts/public/issues/35601 **Recommend ignoring whitespace for diff** I'm looking for feedback on the implementation and if accepted, I will update docs / tests as required. Allow an optional service account name reference to workload podSpec. This PR purposes adding new field to `workload.$name.podSpec` entitled `overrideServiceAccountName`. ## How to Use Add the `overrideServiceAccountName` field to your workload's `podSpec` in your values.yaml: ```yaml workload: main: enabled: true primary: true type: Deployment podSpec: overrideServiceAccountName: "my-service-account" containers: main: enabled: true ``` **⚙️ Type of change** - [X] ⚙️ Feature/App addition - [ ] 🪛 Bugfix - [ ] ⚠️ Breaking change (fix or feature that would cause existing functionality to not work as expected) - [ ] 🔃 Refactor of current code - [ ] 📜 Documentation Changes **🧪 How Has This Been Tested?** Yes ``` helm template blah . --set workload.main.podSpec.overrideServiceAccountName=my-service-account -f ./default-values.yaml | grep serviceAccountName serviceAccountName: my-service-account ``` **📃 Notes:** When `overrideServiceAccountName` is specified: 1. The chart will use this value directly as the `serviceAccountName` in the pod spec 2. It will bypass the normal service account selection logic 3. The specified service account must already exist in the cluster 4. The service account must exist in the same namespace as the workload 5. You can still define service accounts in the chart for other workloads This is a useful feature when you want to share a common service account across many pods/applications. Side note, many other charts support this feature. The default chart when you run `helm create` also has this feature. **✔️ Checklist:** - [X] ⚖️ My code follows the style guidelines of this project - [X] 👀 I have performed a self-review of my own code - [X] #️⃣ I have commented my code, particularly in hard-to-understand areas - [ ] 📄 I have made changes to the documentation - [ ] 🧪 I have added tests to this description that prove my fix is effective or that my feature works - [ ] ⬆️ I increased versions for any altered app according to semantic versioning - [X] I made sure the title starts with `feat(chart-name):`, `fix(chart-name):`, `chore(chart-name):`, `docs(chart-name):` or `fix(docs):` **➕ App addition** None --- --------- Signed-off-by: Alfred Göppel <43101280+alfi0812@users.noreply.github.com> Co-authored-by: Stavros Kois <s.kois@outlook.com> Co-authored-by: Alfred Göppel <43101280+alfi0812@users.noreply.github.com>
Chart Docs
News
- To add new authors, add their username in the
authors.tsfile insrc/content/docs/news/authors.ts. - News Posts must have these fields in the
frontmatter:titleslug(must start withnews/)dateauthors(The key in theauthorsobject insrc/content/docs/news/authors.ts)
Supported Code Block Languages
Check upstream docs
🧞 Commands
All commands are run from the root of the project, from a terminal:
| Command | Action |
|---|---|
npm install |
Installs dependencies |
npm run dev |
Starts local dev server at localhost:4321 |
npm run dev-windows |
Starts local dev server on windows machines |
npm run build |
Build your production site to ./dist/ |
npm run preview |
Preview your build locally, before deploying |
npm run astro ... |
Run CLI commands like astro add, astro check |
npm run astro -- --help |
Get help using the Astro CLI |
Starlight looks for .md or .mdx files in the src/content/docs/ directory. Each file is exposed as a route based on its file name.
Images can be added to src/assets/ and embedded in Markdown with a relative link.
Static assets, like favicons, can be placed in the public/ directory.
👀 Want to learn more?
Check out Starlight’s docs, read the Astro documentation, or jump into the Astro Discord server.