vikunja
/
helm-chart
2
2
Fork 5
Code Issues 7 Pull Requests Packages Projects Releases 1 Wiki Activity

Move README.md components around
continuous-integration/drone/pr Build is passing Details

This commit is contained in:
perf3ct 2023-11-02 12:34:45 -07:00
parent e09afb9e25
commit ce56e07518
No known key found for this signature in database
GPG Key ID: 569C4EEC436F5232
1 changed files with 43 additions and 43 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

86
README.md
View File

@ -14,49 +14,6 @@ The majority of default values defined in `values.yaml` should be compatible for
That should be it!
### Registration (creating users)
You can disable registration (if you do not with to allow others to register on your Vikunja), by providing the following values in your `values.yaml`:
```yaml
api:
configMaps:
config:
enabled: true
data:
config.yml:
service:
enableregistration: false
```
If you need to create another user, you could opt to execute the following command on the `api` container:
```bash
./vikunja user create --email <user@email.com> --user <user1> --password <password123>
```
### Modifying Deployed Resources
Often times, modifications need to be made to a Helm chart to allow it to operate in your Kubernetes cluster. By utilizing bjw-s's `common` library, there are quite a few options that can be easily modified.
Anything you see [here](https://github.com/bjw-s/helm-charts/blob/a081de53024d8328d1ae9ff7e4f6bc500b0f3a29/charts/library/common/values.yaml), including the top-level keys, can be added and subtracted from this chart's `values.yaml`, underneath the `api`, `frontend`, and (optionally) `typesense` key.
For example, if you wished to create a `serviceAccount` as can be seen [here](https://github.com/bjw-s/helm-charts/blob/a081de53024d8328d1ae9ff7e4f6bc500b0f3a29/charts/library/common/values.yaml#L85-L87) for the `api` pod:
```yaml
api:
serviceAccount:
create: true
```
Then, (for some reason), if you wished to deploy the `frontend` as a `DaemonSet` ([as can be seen here](https://github.com/bjw-s/helm-charts/blob/a081de53024d8328d1ae9ff7e4f6bc500b0f3a29/charts/library/common/values.yaml#L12-L17)), you could do the following:
```yaml
frontend:
controller:
type: daemonset
```
### Use an existing file volume claim
In the `values.yaml` file, you can either define your own existing Persistent Volume Claim (PVC) or have the chart create one on your behalf.
@ -85,6 +42,49 @@ api:
storageClass: storage-class
```
### Modifying Deployed Resources
Often times, modifications need to be made to a Helm chart to allow it to operate in your Kubernetes cluster. By utilizing bjw-s's `common` library, there are quite a few options that can be easily modified.
Anything you see [here](https://github.com/bjw-s/helm-charts/blob/a081de53024d8328d1ae9ff7e4f6bc500b0f3a29/charts/library/common/values.yaml), including the top-level keys, can be added and subtracted from this chart's `values.yaml`, underneath the `api`, `frontend`, and (optionally) `typesense` key.
For example, if you wished to create a `serviceAccount` as can be seen [here](https://github.com/bjw-s/helm-charts/blob/a081de53024d8328d1ae9ff7e4f6bc500b0f3a29/charts/library/common/values.yaml#L85-L87) for the `api` pod:
```yaml
api:
serviceAccount:
create: true
```
Then, (for some reason), if you wished to deploy the `frontend` as a `DaemonSet` ([as can be seen here](https://github.com/bjw-s/helm-charts/blob/a081de53024d8328d1ae9ff7e4f6bc500b0f3a29/charts/library/common/values.yaml#L12-L17)), you could do the following:
```yaml
frontend:
controller:
type: daemonset
```
### Another Example of Modifying `config.yml` (Enabling Registration)
You can disable registration (if you do not with to allow others to register on your Vikunja), by providing the following values in your `values.yaml`:
```yaml
api:
configMaps:
config:
enabled: true
data:
config.yml:
service:
enableregistration: false
```
If you need to create another user, you could opt to execute the following command on the `api` container:
```bash
./vikunja user create --email <user@email.com> --user <user1> --password <password123>
```
## Publishing
The following steps are automatically performed when a git tag for a new version is pushed to the repository.