allanger/helmule
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Activity

Remove trailing whitespaces in README

Browse Source
This commit is contained in:
Nikolai Rodionov 2024-01-17 11:05:52 +01:00
parent 9f04812bcf
commit c4bc647ce9
Signed by: allanger
GPG Key ID: 0AA46A90E25592AD
1 changed files with 20 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

40
README.md
View File

@ -17,11 +17,11 @@ mirrors: {}
``` ```
Currently there are two types of mirrors that are supported: Currently there are two types of mirrors that are supported:
- Git - Git
- Custom Comand - Custom Comand
Let's start with git. Let's start with git.
```yaml ```yaml
# Basic example # Basic example
@ -33,7 +33,7 @@ mirrors:
path: charts/something path: charts/something
commit: |- commit: |-
chore: mirror something chore: mirror something
``` ```
As you can see, it won't work on scale, so all the field can be templated using the chart data and a couple of helpers. As you can see, it won't work on scale, so all the field can be templated using the chart data and a couple of helpers.
@ -77,7 +77,7 @@ Also you can provide `rebase<bool>` and `default_branch<string>`, if you want he
That would be it for git, and now the second option: CustomCommand That would be it for git, and now the second option: CustomCommand
The process of mirroring is split into two parts: The process of mirroring is split into two parts:
- Package - Package
- Upload - Upload
The second is being executed only if you don't run in the `dry-run` mode. Git mirror handles it in code. But for custom command you'll have to define it yourself. Just check the following example: The second is being executed only if you don't run in the `dry-run` mode. Git mirror handles it in code. But for custom command you'll have to define it yourself. Just check the following example:
@ -127,7 +127,7 @@ charts:
# the name of the repo from the .repositories # the name of the repo from the .repositories
repository: flux-community repository: flux-community
# it will be latest if not provided, or you can fix it here # it will be latest if not provided, or you can fix it here
# #
# but if you use git repos, it makes sense to always use latest # but if you use git repos, it makes sense to always use latest
# becase in a git repo usually there is only one version # becase in a git repo usually there is only one version
# of a chart, and you either need to guess it, or just fix it # of a chart, and you either need to guess it, or just fix it
@ -152,10 +152,10 @@ Until this moment, it looks exactly like a yet another helm chart mirroring solu
--- ---
First one is `extensions` config property. First one is `extensions` config property.
> Currently it will only cope files to your chart after it was pulled from the upstream. But later I plan to add an ability to use variables there, so one extension can more-or-less easily be reused between charts. > Currently it will only cope files to your chart after it was pulled from the upstream. But later I plan to add an ability to use variables there, so one extension can more-or-less easily be reused between charts.
Why would one need it? Well, me for example, in my clusters I use Istio as an ingress controller and db-operator to manage databases, and since usually charts are provided with `ingress` and obviously without `database` custom resources, I can't just use them without modifications. I don't want to modify manifests that are generated by helm, because of many reasons. So I need to have them in the helm chart. Since I'm using helmfile, I can add them as dependencies without forking charts, but it still not the perfect solution I guess. Why would one need it? Well, me for example, in my clusters I use Istio as an ingress controller and db-operator to manage databases, and since usually charts are provided with `ingress` and obviously without `database` custom resources, I can't just use them without modifications. I don't want to modify manifests that are generated by helm, because of many reasons. So I need to have them in the helm chart. Since I'm using helmfile, I can add them as dependencies without forking charts, but it still not the perfect solution I guess.
So, here come extensions. You can create a `VirtualService` and a `Database`, let's say you've created something like that: So, here come extensions. You can create a `VirtualService` and a `Database`, let's say you've created something like that:
``` ```
@ -166,7 +166,7 @@ extensions
virtual-service.yaml virtual-service.yaml
``` ```
And then you can add it to you helmule config And then you can add it to you helmule config
```yaml ```yaml
charts: charts:
@ -192,13 +192,13 @@ And if you run helmule now, you'll see additional resources added to the chart.
--- ---
The second feature is `patches`. Those are supposed to be modifications to helm chart that require more logic than just copy-paste. The second feature is `patches`. Those are supposed to be modifications to helm chart that require more logic than just copy-paste.
There are 4 kinds of patches at the moment. There are 4 kinds of patches at the moment.
1. Regexp patch. This one will create a regexp and try to replace it with desired value. It's not checking if anything was actually changed though. It can be defined like that 1. Regexp patch. This one will create a regexp and try to replace it with desired value. It's not checking if anything was actually changed though. It can be defined like that
```yaml ```yaml
charts: charts:
- name: flux2 - name: flux2
patches: patches:
- name: Some regexp patch - name: Some regexp patch
@ -222,7 +222,7 @@ It was the first kind of patch added, so it's more or less POC. I wouldn't recom
2. Git patch. You see "Git" here, but it doesn't mean that it's working only with git repos. What it's doing is it's initializing a git repo in the chart dir, and trying to apply a git patch you've provided. To create one, you could use a flag `--init-git-patch $CHART_NAME_1,$CHART_NAME_2`. Then helmule won't try to mirror charts that are listed under that flug, but it will init git repos in their root folders and prints paths to them, so you can go there, change something, execute `git diff > $CONFIG_DIR/chart.patch` and then add it to the config like that: 2. Git patch. You see "Git" here, but it doesn't mean that it's working only with git repos. What it's doing is it's initializing a git repo in the chart dir, and trying to apply a git patch you've provided. To create one, you could use a flag `--init-git-patch $CHART_NAME_1,$CHART_NAME_2`. Then helmule won't try to mirror charts that are listed under that flug, but it will init git repos in their root folders and prints paths to them, so you can go there, change something, execute `git diff > $CONFIG_DIR/chart.patch` and then add it to the config like that:
```yaml ```yaml
charts: charts:
- name: flux2 - name: flux2
patches: patches:
- name: Some git patch - name: Some git patch
@ -256,7 +256,7 @@ charts:
It's also possible to re-use patches by different charts. If you have a common patch, you can define it on the root level of you config: It's also possible to re-use patches by different charts. If you have a common patch, you can define it on the root level of you config:
```yaml ```yaml
charts: {} charts: {}
patches: patches:
- name: yamlfmt - name: yamlfmt
custom_command: custom_command:
commands: commands:
@ -268,11 +268,11 @@ patches:
And then, if you define a patch with the name only for a chart, it's going to be taken from global patches And then, if you define a patch with the name only for a chart, it's going to be taken from global patches
```yaml ```yaml
charts: charts:
- name: flux2 - name: flux2
patches: patches:
- name: yamlfmt - name: yamlfmt
patches: patches:
- name: yamlfmt - name: yamlfmt
custom_command: custom_command:
commands: commands:
@ -285,7 +285,7 @@ patches:
One last thing that is not described yet is the `include` property. It looks like that: One last thing that is not described yet is the `include` property. It looks like that:
```yaml ```yaml
include: include:
- kind Charts # Can also be Repositories and Mirrors, other properties will be includable later - kind Charts # Can also be Repositories and Mirrors, other properties will be includable later
path: ./charts.yaml path: ./charts.yaml
charts: {} charts: {}
@ -297,7 +297,7 @@ The included file will be marshalled into a vector of desired property. But the
# charts.yaml # charts.yaml
name: flux2 name: flux2
repository: flux-community repository: flux-community
mirrors: mirrors:
- my-git-mirror - my-git-mirror
``` ```
@ -305,6 +305,6 @@ mirrors:
# charts.yaml # charts.yaml
- name: flux2 - name: flux2
repository: flux-community repository: flux-community
mirrors: mirrors:
- my-git-mirror - my-git-mirror
``` ```