### Description of the change
Fix a wrong reference to `signing.existingKey`, `signing.existingSecret` was what was meant and what is used in the chart.
### Benefits
Less confusion when trying to use the Helm chart.
### Possible drawbacks
Evangelists of `existingKey` storming the barricades even though `existingKey` is long dead.
### Applicable issues
None, nobody noticed enough to care, apparently.
Co-authored-by: Tobias Wolter <towo@towo.eu>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/415
Reviewed-by: pat-s <pat-s@noreply.gitea.io>
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-authored-by: towo <towo@noreply.gitea.io>
Co-committed-by: towo <towo@noreply.gitea.io>
### Description of the change
Corrects the spelling of the word deprecated.
### Benefits
Documentation free of misspelled words is more likely to be viewed as "professional".
### Possible drawbacks
None that I can think of
### Applicable issues
- fixes#393
### Additional information
There may be other misspelled words or incorrectly phrased passages that aren't addressed in this PR.
For reference, see the online dictionary for the correct spelling of deprecated.
https://www.merriam-webster.com/dictionary/deprecated
### Checklist
- [X] Parameters are documented in the `values.yaml` and added to the `README.md` using [readme-generator-for-helm](https://github.com/bitnami-labs/readme-generator-for-helm)
- [X] Breaking changes are documented in the `README.md`
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/394
Reviewed-by: pat-s <pat-s@noreply.gitea.io>
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-authored-by: robv89r <robv8r@noreply.gitea.io>
Co-committed-by: robv89r <robv8r@noreply.gitea.io>
<!--
Before you open the request please review the following guidelines and tips to help it be more easily integrated:
- Describe the scope of your change - i.e. what the change does.
- Describe any known limitations with your change.
- Please run any tests or examples that can exercise your modified code.
Thank you for contributing! We will try to review, test and integrate the change as soon as we can.
-->
### Description of the change
Exluding non helm chart related files from release artifact
### Benefits
Smaller release artifacts
### Possible drawbacks
Exluded files not visible any within the artifact
### Applicable issues
None
### Additional information
None
### ⚠ BREAKING
None
### Checklist
<!-- [Place an '[X]' (no spaces) in all applicable fields. Please remove unrelated fields.] -->
- [x] Parameters are documented in the `values.yaml` and added to the `README.md` using [readme-generator-for-helm](https://github.com/bitnami-labs/readme-generator-for-helm)
- [x] Breaking changes are documented in the `README.md`
Co-authored-by: Julian Schlarb <js@project-deadline.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/385
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Reviewed-by: pat-s <pat-s@noreply.gitea.io>
Co-authored-by: JSchlarb <jschlarb@noreply.gitea.io>
Co-committed-by: JSchlarb <jschlarb@noreply.gitea.io>
### Description of the change
This PR adds support for gpg key setup. It allows to pass the gpg private key content inline inside `values.yaml` or refer to an existing secret containing the key content data.
### Benefits
Administrators don't need to manually setup the gpg environment from inside a running container. It also eliminates the breaking change of Gitea 1.17 regarding `[git].HOME` as the `GNUPGHOME` environment variable is used consistently to relocate the `.gnupg` directory to its former location.
### Applicable issues
- fixes#107
### Additional information
This PR add the first unit tests to this Helm Chart, ensuring templating integrity for signing related configuration.
### Checklist
- [x] Parameters are documented in the `values.yaml` and added to the `README.md` using [readme-generator-for-helm](https://github.com/bitnami-labs/readme-generator-for-helm)
Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com>
Co-authored-by: pat-s <pat-s@noreply.gitea.io>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/343
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: techknowlogick <techknowlogick@gitea.io>
Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
### Description of the change
Checking the existence of the config directory should be done with the directory path itself. Not its parent directory.
This simple fix addresses that by using the config directory for its existence check.
### Benefits
Prior to #337 there was no other way to install this helm chart using the `extraVolumeMounts` setting with these values:
```yaml
replicaCount: %d
extraVolumes:
- name: config-volume
configMap:
name: %s
extraVolumeMounts:
- name: config-volume
mountPath: /data/gitea/templates/custom
```
Without this fix, the Gitea pod would never initialize, and would crashloop with the same error in #296.
### Additional information
Mounting a configMap to `/data/gitea/templates/custom` causes the `/data/gitea` folder to exist even though the `/data/gitea/conf` had not been initialized yet. The initialization script saw that the `/data/gitea` dir existed and exited early without initializing `/data/gitea/conf`.
Co-authored-by: cboin1996 <christianboin@hotmail.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/310
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Reviewed-by: pat-s <pat-s@noreply.gitea.io>
Co-authored-by: cboin1996 <cboin1996@noreply.gitea.io>
Co-committed-by: cboin1996 <cboin1996@noreply.gitea.io>
Description of the change
Mostly, this change just moves the changelog to the bottom of the README which helps new users to see the actual documentation. As the structure for the changes itself is slightly different, there are some changes in wording so that it still makes sense. But mostly structural changes.
The change within the dependency section is due to a broken link since auto-generating the parameters section. Now there are links to every dependency related parameters.
Benefits
It helps us to maintain a clear structure for the README of this project.
Possible drawbacks
Our users are currently trained to look at the top of the document to see the changes. They now have to scroll down or use the quick link from installation section.
Applicable issues
fixes#247
Additional information
Every version section starts with a disclaimer right now. This is duplicated and might hide important text due to its existence. A centralized intruduction at top of the upgrading section tells the reader what to expect from that whole section.
I've also noticed that on ArtifactHub the emotes are not rendered correctly. So I replaced them with the actual ones and reduced their usage. That way it better highlights those parts the reader must not miss.
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/331
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: techknowlogick <techknowlogick@gitea.io>
Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
## Context
PR #259 introduced support for running Gitea as a uid different than 1000 (git) or 0 (root).
## Problem
In init_directory_structure.sh, there is a "chown 1000:1000" on /tmp/gitea.
This chown only works when running as root or when the target directory is already owned by uid 1000.
As a result, the init container "init-directories" fails on startup when running Gitea with a uid different from 0 or 1000.
Initially, I worked around it by implementing an "initPreScript". But it would make user's life easier if we can make it work out-of-the-box.
## Resolution
I'm taking model on the chown a few lines above that depends on the value of image.rootless. Since the chown only works on default (root) image and is useless on rootless image, there is no need to run it on rootless image.
Co-authored-by: Nicolas MASSE <nicolas.masse@itix.fr>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/266
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-authored-by: nmasse-itix <nmasse-itix@noreply.gitea.io>
Co-committed-by: nmasse-itix <nmasse-itix@noreply.gitea.io>
With release 5.0.0 there are so many deprecations and breaking changes
that it is probably a good way to assist the users with values migration
before breaking their environments.
This adds another template file that doesn't render anything but ensures
the removal of dropped or deprecated settings from customized values
files.
For when it is necessary, this check can be disabled via new setting
`checkDeprecation`.
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/269
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: wxiaoguang <wxiaoguang@noreply.gitea.io>
Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
With the result of PR #239 it is much easier to provide additional values to the _app.ini_ configuration from different sources.
These changes adds an _additionalConfigSources_ field where the users can define such sources. This enables the users to choose
on their own whether to store values in _values.yaml_ or load them from Kuberetes Secrets or ConfigMaps.
- Fixes#243
- Fixes#174
- Fixes#260
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/240
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: wxiaoguang <wxiaoguang@noreply.gitea.io>
Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Hello !
I'm using the new Helm chart (5.x) and I really like the new configuration mechanism. 👍
I would like to contribute the following enhancement.
## The problem I want to solve
I'm trying to deploy Gitea in a Kubernetes shared platform and I need to make sure each instance is running as a different user so that in case of container escape, the risk of data leak is minimized.
Additionally, on my platform (OpenShift), arbitrary users (such as uid 1000 for Gitea) are not allowed.
The current helm chart does not allow me to achieve this because:
- the container security context is configurable only for the main container. The security context of init containers cannot be specified.
- a fixed uid is hard coded
- a fixed fs group is hard coded
Also, the securityContext of a pod and the securityContext of a container do not accept the same options.
- https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#podsecuritycontext-v1-core
- https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#securitycontext-v1-core
## How I'm solving the problem
I split the `securityContext` (values.yaml) in two: `containerSecurityContext` and `podSecurityContext`. The containerSecurityContext applies to all containers (init and main) in order to be consistent with file permissions.
The behavior for existing deployments is unchanged:
- fsGroup 1000 is the default value for the podSecurityContext variable
- the "configure-gitea" init container uses the uid 1000 unless otherwise stated in the containerSecurityContext
- the main container is using the existing securityContext variable when defined in order not to break existing deployments and uses the new containerSecurityContext variable if not.
This approach is well tested: it is used consistently on bitnami's Helm charts.
## How I tested
I tested both root and rootless variants on a Kubernetes 1.22, as well as rootless variant on OpenShift 4.7.
**rootless variant on Kubernetes**:
```yaml
podSecurityContext:
fsGroup: 10001
containerSecurityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL
add:
- SYS_CHROOT
privileged: false
runAsGroup: 10001
runAsNonRoot: true
runAsUser: 10001
extraVolumes:
- name: var-lib-gitea
emptyDir: {}
extraVolumeMounts:
- name: var-lib-gitea
readOnly: false
mountPath: "/var/lib/gitea"
```
**rootless variant on OpenShift**:
```yaml
podSecurityContext:
fsGroup: null
containerSecurityContext:
allowPrivilegeEscalation: false
privileged: false
runAsNonRoot: true
runAsUser: 1000790000
extraVolumes:
- name: var-lib-gitea
emptyDir: {}
extraVolumeMounts:
- name: var-lib-gitea
readOnly: false
mountPath: "/var/lib/gitea"
```
Let me know if something is unclear.
Co-authored-by: Nicolas MASSE <nicolas.masse@itix.fr>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/259
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-authored-by: nmasse-itix <nmasse-itix@noreply.gitea.io>
Co-committed-by: nmasse-itix <nmasse-itix@noreply.gitea.io>
Currently there are two different styles for defining both ldap and oauth configuration in _values.yaml_ file: `camelCase` and `kebab-case`.
Supporting both styles created multiple regressions in the past.
⚠️ BREAKING ⚠️
---------------
These changes completely remove any support for `kebab-case` notation in _values.yaml_ in favor of `camelCase`. Configuration keys must use `camelCase`.
Only exception are Kubernetes resource keys for annotations or labels.
Fixes: #188
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/196
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
These changes rewrite the init script to be error aware, informative and have a bit more security awareness.
During rewrite several hidden bugs could be identified and fixed, such as:
- LDAP configuration options interpreted by the shell before passed to command
- Finding multiple ldap ids instead of one during lookup when their names are almost identical
e.g. `_my-ldap-auth` and `my-ldap-auth`
- Properly filter auth sources by their types to prevent unintended type converting attempts that fail
In addition to that the script is a bit cleaner. Some commands do not exist anymore and would cause false-positive errors during script execution.
Helps for: #149
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/178
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: techknowlogick <techknowlogick@gitea.io>
Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
The `HOME` path is not persistent when using the rootless image, so the
`.gnupg` folder isn't either. Since the chart always used `/data/...` as
mount point for storage of all kinds, it is a minimal impact to just
relocate the dynamic `$HOME/.gnupg` folder location to the persistent
`/data/git/.gnupg`. This is where the signing keys are stored when
running root based environments. Doing so will
- allow migrations between both image variants
- persist signing keys for rootless environments
Fixes: #155
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/186
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: techknowlogick <techknowlogick@gitea.io>
Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
I've noticed that the commented `securityContext` is not really useable with the rootless image due to different directory structure compared to the default image.
Important for the `readOnlyRootFilesystem` is to declare the `TMPDIR` environment variable, so that the tmp directory (which is readonly in this case) won't be used. Instead, another writeable directory can be used.
Another thing is the explicit hint that all these security options cannot be used with the default (root-based) image, because of its design.
~~Although this PR would fix the referenced issue, I am not totally happy with the current implementation. It would be more straight forward to use the same mount points for both image variants. Unfortunately, this is not possible right now due to hard coded paths in the default (root) image startup scripts.~~
~~Anyone have suggestions on how this could be more simple?~~
-------
**Sum-up:**
As mentioned in Discord, this PR tried to make too many changes. The necessary changes made in 1f331a7e6577fc798196a84a957330aca0d663cd will fix an error that occurs due to restricted access to the `/tmp` directory in a rootless image with all the `securityContext` options enabled.
I also updated the default image to 1.14.2.
Fixes: #158
Co-authored-by: JustusBunsi <sk.bunsenbrenner@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/160
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: 6543 <6543@obermui.de>
Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
This change adds a new value *statefulset.labels* to allow the user to add custom labels to the StatefulSet.
An example of where this could be useful is if gitea's pvc is stored on OpenEBS. With this new option, the user can add the extra *openebs.io/sts-target-affinity* label to specify that the volume target pod should run on the same node as gitea's StatefulSet.
Co-authored-by: Baptiste Covolato <b.covolato@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/130
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: lafriks <lafriks@noreply.gitea.io>
Co-authored-by: Nakrez <nakrez@noreply.gitea.io>
Co-committed-by: Nakrez <nakrez@noreply.gitea.io>
There are currently 2 issues that prevent using this chart to deploy gitea with a SQLite3 database.
1) The value from *gitea.config.database.HOST* is used to set *db.servicename* when all the databases under *gitea.database.buildIn* are not enabled. This causes a type error during the template processing:
`Error: UPGRADE FAILED: template: gitea/templates/gitea/init.yaml:24:20: executing "gitea/templates/gitea/init.yaml" at <include "db.servicename" .>: error calling include: template: gitea/templates/_helpers.tpl:64:31: executing "db.servicename" at <.Values.gitea.config.database.HOST>: wrong type for value; expected string; got interface {}`
2) In *init_gitea.sh*, we use the value *db.servicename* and *db.port* to ping the database. If this database responds to ping, we proceed with the init. The problem here is that *db.port* is not set when all the databases under *gitea.database.buildIn* are disabled. In turn, this raises an error from busybox's *nc*, because no parameter is passed for *PORT*. This causes the init container to go in *CrashLoopBackOff* forever.
The simple fix that is proposed in this PR is to check wether or not *.Values.gitea.config.database.DB_TYPE* is set to determine the value *db.servicename*. If *DB_TYPE* is *'sqlite3'*, leave *db.servicename* empty and use that to bypass the database ping.
Co-authored-by: Baptiste Covolato <b.covolato@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/124
Reviewed-by: Andrew Thornton <art27@cantab.net>
Reviewed-by: lafriks <lafriks@noreply.gitea.io>
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Co-authored-by: Nakrez <nakrez@noreply.gitea.io>
Co-committed-by: Nakrez <nakrez@noreply.gitea.io>
This pull request adds the `app` and `version` labels that are used by Istio.
> Pods with app and version labels: We recommend adding an explicit app label and version label to the specification of the pods deployed using a Kubernetes Deployment. The app and version labels add contextual information to the metrics and telemetry that Istio collects.
>
> * The app label: Each deployment should have a distinct app label with a meaningful value. The app label is used to add contextual information in distributed tracing.
>
> * The version label: This label indicates the version of the application corresponding to the particular deployment.
From https://istio.io/latest/docs/ops/deployment/requirements/#pod-requirements
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/121
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: lafriks <lafriks@noreply.gitea.io>
Co-authored-by: Starefossen <starefossen@noreply.gitea.io>
Co-committed-by: Starefossen <starefossen@noreply.gitea.io>
This PR adds a few new chart features which adds to the flexibility of the chart.
- allow extra volumes to be mounted (such as secrets): 2f862c5a48
- pass environment variables also to the init-container: 7044049478
- allow a preparation script to be "injected" into the init-container: 6125a69345
As a concrete example of how this can be used, I use is to configure Gitea to use client certificate authentication against an external Postgres database. That could be accomplished by having a `gitea-postgres-ssl` secret:
```
apiVersion: v1
kind: Secret
type: Opaque
metadata:
name: gitea-postgres-ssl
data:
postgresql.crt: <base64...>
postgresql.key: <base64...>
root.crt: <base64...>
```
and then mounting this as a volume in Gitea using:
```
extraVolumes:
- name: postgres-ssl-vol
secret:
secretName: gitea-postgres-ssl
extraVolumeMounts:
- name: postgres-ssl-vol
readOnly: true
mountPath: "/pg-ssl"
```
To get the right permissions on the credentials, we'd use the `initPreScript`:
```
initPreScript: |
# copy postgres client and CA cert from mount and
# give proper permissions
mkdir -p /data/git/.postgresql
cp /pg-ssl/* /data/git/.postgresql/
chown -R git:git /data/git/.postgresql/
chmod 400 /data/git/.postgresql/postgresql.key
```
and to make sure that Gitea uses the certificate we need to pass the proper postgres environment variables (both to the init container and the "main" container):
```
statefulset:
env:
- name: "PGSSLCERT"
value: "/data/git/.postgresql/postgresql.crt"
- name: "PGSSLKEY"
value: "/data/git/.postgresql/postgresql.key"
- name: "PGSSLROOTCERT"
value: "/data/git/.postgresql/root.crt"
```
Co-authored-by: Peter Gardfjäll <peter.gardfjall.work@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/47
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: 6543 <6543@obermui.de>
Co-authored-by: petergardfjall <petergardfjall@noreply.gitea.io>
Co-committed-by: petergardfjall <petergardfjall@noreply.gitea.io>
Before you open the request please review the following guidelines and tips to help it be more easily integrated:
-Describe the scope of your change - i.e. what the change does.
-Describe any known limitations with your change.
-Please run any tests or examples that can exercise your modified code.
Thank you for contributing! We will try to review, test and integrate the change as soon as we can.
-->
### Description of the change
<!-- Describe the scope of your change - i.e. what the change does. -->
### Benefits
<!-- What benefits will be realized by the code change? -->
### Possible drawbacks
<!-- Describe any known limitations with your change -->
### Applicable issues
<!-- Enter any applicable Issues here (You can reference an issue using #). Please remove this section if there is no referenced issue. -->
- fixes #
### Additional information
<!-- If there's anything else that's important and relevant to your pull request, mention that information here. Please remove this section if it remains empty. -->
### ⚠ BREAKING
<!-- If there's a breaking change, please shortly describe in which way users are affected and how they can mitigate it. If there are no breakings, please remove this section. -->
### Checklist
<!-- [Place an '[X]' (no spaces) in all applicable fields. Please remove unrelated fields.] -->
- [ ] Parameters are documented in the `values.yaml` and added to the `README.md` using [readme-generator-for-helm](https://github.com/bitnami-labs/readme-generator-for-helm)
- [ ] Breaking changes are documented in the `README.md`
{{- fail "`gitea.customLivenessProbe` does no longer exist. Please refer to the changelog and configure `gitea.livenessProbe` instead." -}}
{{- end -}}
{{- if .Values.gitea.customReadinessProbe -}}
{{- fail "`gitea.customReadinessProbe` does no longer exist. Please refer to the changelog and configure `gitea.readinessProbe` instead." -}}
{{- end -}}
{{- if .Values.gitea.customStartupProbe -}}
{{- fail "`gitea.customStartupProbe` does no longer exist. Please refer to the changelog and configure `gitea.startupProbe` instead." -}}
{{- end -}}
{{/* LDAP SOURCES */}}
{{- if kindIs "map" .Values.gitea.ldap -}}
{{- fail "You can configure multiple LDAP sources. Please refer to the changelog and switch `gitea.ldap` from object to array notation." -}}
{{- end -}}
{{/* OAUTH SOURCES */}}
{{- if kindIs "map" .Values.gitea.oauth -}}
{{- fail "You can configure multiple OAuth sources. Please refer to the changelog and switch `gitea.oauth` from object to array notation." -}}
{{- end -}}
{{/* BUILTIN */}}
{{- if .Values.gitea.cache -}}
{{- if .Values.gitea.cache.builtIn -}}
{{- fail "`gitea.cache.builtIn` does no longer exist. Please use `memcached` at root level instead." -}}
{{- end -}}
{{- end -}}
{{- if .Values.gitea.database -}}
{{- if .Values.gitea.database.builtIn -}}
{{- fail "`gitea.database.builtIn` does no longer exist. Builtin databases can be configured inside the dependencies itself. Please refer to the changelog." -}}
File diff suppressed because it is too large
Load Diff
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
