**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>
title
| title |
|---|
| TrueCharts |
Community Helm Chart Catalog
TrueCharts is a catalog of highly optimised Helm Charts. Made for the community, By the community!
All our charts are supposed to work together and be easy to setup using any helm-compatible deployment tool, above all, give the average user more than enough options to tune things to their liking.
Getting started using TrueCharts
Support
Please check our FAQ, manual and Issue tracker There is a significant chance your issue has been reported before!
Still something not working as expected? Contact us! and we'll figure it out together!
Development
Our development process is fully distributed and agile, so every chart-maintainer is free to set their own roadmap and development speed and does not have to comply to a centralised roadmap. This ensures freedom and flexibility for everyone involved and makes sure you, the end user, always has the latest and greatest of every Chart installed.
Getting into creating Charts
For more information check the website: https://truecharts.org
Contact and Support
To contact the TrueCharts project:
-
Create an issue on Github issues
-
Open a Support Ticket
-
Send us an email
Contributors ✨
Thanks goes to these wonderful people (emoji key):
This project follows the all-contributors specification. Contributions of any kind welcome!
Licence
Truecharts, is primarily based on a AGPL-v3 license, this ensures almost everyone can use and modify our charts. Licences can vary on a per-Chart basis. This can easily be seen by the presence of a "LICENSE" file in said folder.
An exception to this, has been made for every document inside folders labeled as docs or doc and their subfolders: those folders are not licensed under AGPL-v3 and are considered "all rights reserved". Said content can be modified and changes submitted per PR, in accordance to the github End User License Agreement.
SPDX-License-Identifier: AGPL-3.0