feat: support templates #235

volker.raschek · 2021-10-30T11:39:38Z

volker.raschek commented

2021-10-30 11:39:38 +00:00

this patch support the creation of template files for repository labels and the .gitignore, LICENSE and README.md files, which can be selected during the create of a new repository.

Sideeffect of the PR is, that the the directory structure, created via kubernetes, is also listed in the drop down menue. Here a screenshot of my custom labels grouped as myLabels. This listing issue should be fixed directly via gitea. Here the related issue.

Hi @lunny and @justusbunsi, this patch support the creation of template files for repository labels and the `.gitignore`, `LICENSE` and `README.md` files, which can be selected during the create of a new repository. Sideeffect of the PR is, that the the directory structure, created via kubernetes, is also listed in the drop down menue. Here a screenshot of my custom labels grouped as `myLabels`. This listing issue should be fixed directly via gitea. Here the related [issue](https://github.com/go-gitea/gitea/issues/17490).

Bildschirmfoto vom 2021-10-30 13-28-13.png

50 KiB

volker.raschek added 1 commit 2021-10-30 11:39:39 +00:00

feat: support templates

continuous-integration/drone/pr Build is passing

Details

ad87059e8d

justusbunsi commented

2021-10-30 12:02:30 +00:00

+values2.yaml

Local files that should be excluded on a local machine could be added to .git/info/exclude file. That way it would keep the gitignore file clean. But I don't block this if it's kept that way. ?

``` +values2.yaml ``` Local files that should be excluded on a local machine could be added to .git/info/exclude file. That way it would keep the gitignore file clean. But I don't block this if it's kept that way. ?

justusbunsi commented

2021-10-30 12:06:03 +00:00

+  labels:

Is there a reason to have several dedicated configmaps instead one customizing configmaps storing all those values? Would this make it more complicated to implement?

``` + labels: ``` Is there a reason to have several dedicated configmaps instead one customizing configmaps storing all those values? Would this make it more complicated to implement?

volker.raschek commented

2021-10-30 12:15:13 +00:00

Hi @justusbunsi,

I tried first to use only one config map. With for example labels/{{ key }}: {{ value }}, gitignore/{{ key }}: {{ value }} and so on as key value pairs. But the slash, which is required to place the file into the right directory is an unsupported char.

Fot this reason I decided to create seperate config maps. I am open for suggestions for improvements if you or another developer has a better idea to solve the problem.

Hi @justusbunsi, I tried first to use only one config map. With for example `labels/{{ key }}: {{ value }}`, `gitignore/{{ key }}: {{ value }}` and so on as key value pairs. But the slash, which is required to place the file into the right directory is an unsupported char. Fot this reason I decided to create seperate config maps. I am open for suggestions for improvements if you or another developer has a better idea to solve the problem.

justusbunsi commented

2021-10-30 12:53:31 +00:00

I wasn't aware of the required folder structure. That is a good point against one single configmap.
It could be possible to use key prefixes such as labels_ and so on to distinguish between the different subdirectory structure. This would require using an additional init container to provide a corresponding file structure to Gitea or extend an existing one. As Gitea resolves symlinks (files colocated with ..data directory are and they do work in the drop down), we could work with symlinks inside an emptydir with the correct directory structure. IIRC an emptydir type doesn't contain that ..data folder and it would be possible to prevent having those in the drop down list.

This implies a more complex implementation than just mount the configmaps to the correct place and I'm not 100% sure that this is really a good end result. What do you think @luhahn?

I wasn't aware of the required folder structure. That is a good point against one single configmap. It could be possible to use key prefixes such as `labels_` and so on to distinguish between the different subdirectory structure. This would require using an additional init container to provide a corresponding file structure to Gitea or extend an existing one. As Gitea resolves symlinks (files colocated with `..data` directory are and they do work in the drop down), we could work with symlinks inside an `emptydir` with the correct directory structure. IIRC an `emptydir` type doesn't contain that `..data` folder and it would be possible to prevent having those in the drop down list. This implies a more complex implementation than just mount the configmaps to the correct place and I'm not 100% sure that this is really a good end result. What do you think @luhahn?

luhahn commented

2021-11-11 08:38:50 +00:00

Hi and sorry for the late response. I was in hospital and therefore unavailable. Trying to catch up with the PRs right now :)

@volker.raschek
@justusbunsi

Wouldn't it be possible to just use a configmap like this:

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ include "gitea.fullname" . }}-templates
  labels:
    {{- include "gitea.labels" . | nindent 4 }}
data:
  {{- if .Values.customizing.gitignores }}
  gitignores: |-
    {{- /* add .gitignore template files */ -}}
    {{- range $key, $value := .Values.customizing.gitignores }}
    {{ $key }}: {{ $value | quote }}
    {{- end }}    
  {{- end }}
  {{- if .Values.customizing.labels }}
  labels: |-
    {{- /* add .gitignore template files */ -}}
    {{- range $key, $value := .Values.customizing.labels }}
    {{ $key }}: {{ $value | quote }}
    {{- end }}    
  {{- end }}
  ...

And in the statefulset:

volumeMounts:
{{- if .Values.customizing.gitignores }}
  - name: templates
    mountPath: /data/gitea/options/gitignore
    subPath: gitignores
{{- end}}
volumes:
  - name: templates
    configMap:
      name: {{ include "gitea.fullname" . }}-templates

Hi and sorry for the late response. I was in hospital and therefore unavailable. Trying to catch up with the PRs right now :) @volker.raschek @justusbunsi Wouldn't it be possible to just use a configmap like this: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ include "gitea.fullname" . }}-templates labels: {{- include "gitea.labels" . | nindent 4 }} data: {{- if .Values.customizing.gitignores }} gitignores: |- {{- /* add .gitignore template files */ -}} {{- range $key, $value := .Values.customizing.gitignores }} {{ $key }}: {{ $value | quote }} {{- end }} {{- end }} {{- if .Values.customizing.labels }} labels: |- {{- /* add .gitignore template files */ -}} {{- range $key, $value := .Values.customizing.labels }} {{ $key }}: {{ $value | quote }} {{- end }} {{- end }} ... ``` And in the statefulset: ```yaml volumeMounts: {{- if .Values.customizing.gitignores }} - name: templates mountPath: /data/gitea/options/gitignore subPath: gitignores {{- end}} volumes: - name: templates configMap: name: {{ include "gitea.fullname" . }}-templates ```

justusbunsi commented

2021-11-11 10:43:15 +00:00

Not sure if Kubernetes interprets it that way. AFAIK the root key in the data area is the file name. Anything inside is considered file content. But I haven't tested it, so maybe it's something I didn't knew?

justusbunsi added the

kind

feature

label 2021-11-20 17:53:49 +00:00

jouve reviewed 2022-07-13 17:04:53 +00:00

README.md

						
				@ -471,0 +507,4 @@

				      #598546 renovate/rebase ; Rebase branch on base branch via renovate

				```

				#### Lizense templates

jouve commented

2022-07-13 17:04:53 +00:00

License

pat-s commented

2023-03-23 22:09:59 +00:00

@volker.raschek Lot's of conflicts meanwhile but - any plans to continune here? :) I think the general concept/idea would definitely be a nice feature/enhancement.

pat-s commented

2023-04-01 07:28:56 +00:00

Closing here after no response, feel free to open again if desired @volker.raschek.

pat-s closed this pull request

2023-04-01 07:28:56 +00:00

continuous-integration/drone/pr Build is passing

Details

check-and-test / check-and-test (pull_request)

Required

Pull request closed

Please reopen this pull request to perform a merge.

Sign in to join this conversation.

No reviewers

No Milestone

No Assignees

5 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: gitea/helm-chart#235