Commit d6bce64b authored by Amy Qualls's avatar Amy Qualls

Deal with spelling issues throughout docsets

Deal with spelling issues in multiple ways. Add some words to the
spelling exceptions list. Fix misspellings. Turn off spellchecking on
things that shouldn't be in the exceptions list, but we also can't
remove.
parent 55c67b9a
......@@ -2,6 +2,7 @@ Akismet
Alertmanager
Algolia
Alibaba
Aliyun
allowlist
allowlisted
allowlisting
......@@ -34,6 +35,7 @@ autoscaler
autoscales
autoscaling
awardable
awardables
Axios
Azure
B-tree
......@@ -111,6 +113,7 @@ Dangerfile
datetime
Debian
Decompressor
decryptable
deduplicate
deduplicated
deduplicates
......@@ -168,6 +171,7 @@ Figma
Filebeat
Fio
firewalled
firewalling
Flawfinder
Flowdock
Fluentd
......@@ -272,6 +276,7 @@ libFuzzer
Libravatar
liveness
Lograge
logrotate
Logstash
lookahead
lookaheads
......@@ -282,6 +287,7 @@ loopback
Lucene
Maildir
Mailgun
Mailroom
Makefile
Makefiles
Markdown
......@@ -505,6 +511,8 @@ spidering
Splunk
SpotBugs
Stackdriver
starrer
starrers
storable
storages
strace
......@@ -525,6 +533,8 @@ subnet
subnets
subnetting
subpath
subproject
subprojects
subqueried
subqueries
subquery
......@@ -534,9 +544,12 @@ substrings
subtree
subtrees
sudo
supercookie
supercookies
swappiness
swimlane
swimlanes
syncable
Sysbench
syslog
tanuki
......@@ -633,6 +646,9 @@ unresolved
unresolving
unschedule
unscoped
unshare
unshared
unshares
unstage
unstaged
unstages
......
......@@ -530,7 +530,12 @@ The process executes the following access checks:
In Active Directory, a user is marked as disabled/blocked if the user
account control attribute (`userAccountControl:1.2.840.113556.1.4.803`)
has bit 2 set.
For more information, see <https://ctovswild.com/2009/09/03/bitmask-searches-in-ldap/>
<!-- vale gitlab.Spelling = NO -->
For more information, see [Bitmask Searches in LDAP](https://ctovswild.com/2009/09/03/bitmask-searches-in-ldap/).
<!-- vale gitlab.Spelling = YES -->
The user is set to an `ldap_blocked` state in GitLab if the previous conditions
fail. This means the user is not able to sign in or push/pull code.
......
......@@ -175,6 +175,6 @@ If you're having trouble, here are some tips:
OAuth2 access token if `client_auth_method` is not defined or if set to `basic`.
If you are seeing 401 errors upon retrieving the `userinfo` endpoint, you may
want to check your OpenID Web server configuration. For example, for
[oauth2-server-php](https://github.com/bshaffer/oauth2-server-php), you
[`oauth2-server-php`](https://github.com/bshaffer/oauth2-server-php), you
may need to [add a configuration parameter to
Apache](https://github.com/bshaffer/oauth2-server-php/issues/926#issuecomment-387502778).
......@@ -53,7 +53,7 @@ The following are GitLab upgrade validation tests we performed.
- Outcome: Partial success because we did not run the looping pipeline during the demo to validate
zero-downtime.
- Follow up issues:
- [Clarify hup Puma/Unicorn should include deploy node](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5460)
- [Clarify how Puma/Unicorn should include deploy node](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5460)
- [Investigate MR creation failure after upgrade to 12.9.10](https://gitlab.com/gitlab-org/gitlab/-/issues/223282) Closed as false positive.
### February 2020
......@@ -128,7 +128,7 @@ The following are PostgreSQL upgrade validation tests we performed.
PostgreSQL 12 with a database cluster on the primary is not recommended until the issues are resolved.
- Known issues for PostgreSQL clusters:
- [Ensure Patroni detects PostgreSQL update](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5423)
- [Allow configuring permanent replication slots in patroni](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5628)
- [Allow configuring permanent replication slots in Patroni](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5628)
### August 2020
......
......@@ -489,7 +489,7 @@ This experimental implementation has the following limitations:
- Whenever `gitlab-ctl reconfigure` runs on a Patroni Leader instance, there's a
chance the node will be demoted due to the required short-time restart. To
avoid this, you can pause auto-failover by running `gitlab-ctl patroni pause`.
After a reconfigure, it unpauses on its own.
After a reconfigure, it resumes on its own.
For instructions about how to set up Patroni on the primary node, see the
[PostgreSQL replication and failover with Omnibus GitLab](../../postgresql/replication_and_failover.md#patroni) page.
......@@ -645,7 +645,7 @@ With Patroni it's now possible to support that. In order to migrate the existing
1. [Configure a Standby Cluster](#step-2-configure-a-standby-cluster-on-the-secondary-site)
on that single node machine.
You will end up with a "Standby Cluster" with a single node. That allows you to later on add additional patroni nodes
You will end up with a "Standby Cluster" with a single node. That allows you to later on add additional Patroni nodes
by following the same instructions above.
## Troubleshooting
......
......@@ -121,7 +121,7 @@ The following list depicts the network architecture of Gitaly:
- GitLab Shell.
- Elasticsearch indexer.
- Gitaly itself.
- A Gitaly server must be able to make RPC calls **to itself** by uing its own
- A Gitaly server must be able to make RPC calls **to itself** by using its own
`(Gitaly address, Gitaly token)` pair as specified in `/config/gitlab.yml`.
- Authentication is done through a static token which is shared among the Gitaly and GitLab Rails
nodes.
......
......@@ -65,7 +65,7 @@ Gitaly Cluster and [Geo](../geo/index.md) both provide redundancy. However the r
not aware when Gitaly Cluster is used.
- Geo provides [replication](../geo/index.md) and [disaster recovery](../geo/disaster_recovery/index.md) for
an entire instance of GitLab. Users know when they are using Geo for
[replication](../geo/index.md). Geo [replicates multiple datatypes](../geo/replication/datatypes.md#limitations-on-replicationverification),
[replication](../geo/index.md). Geo [replicates multiple data types](../geo/replication/datatypes.md#limitations-on-replicationverification),
including Git data.
The following table outlines the major differences between Gitaly Cluster and Geo:
......
......@@ -24,6 +24,8 @@ The **Kroki URL** is the hostname of the server running the container.
The [`yuzutech/kroki`](https://hub.docker.com/r/yuzutech/kroki) image contains the following diagrams libraries out-of-the-box:
<!-- vale gitlab.Spelling = NO -->
- [Bytefield](https://bytefield-svg.deepsymmetry.org/)
- [Ditaa](http://ditaa.sourceforge.net)
- [Erd](https://github.com/BurntSushi/erd)
......@@ -37,6 +39,8 @@ The [`yuzutech/kroki`](https://hub.docker.com/r/yuzutech/kroki) image contains t
- [Vega-Lite](https://github.com/vega/vega-lite)
- [WaveDrom](https://wavedrom.com/)
<!-- vale gitlab.Spelling = YES -->
If you want to use additional diagram libraries,
read the [Kroki installation](https://docs.kroki.io/kroki/setup/install/#_images) to learn how to start Kroki companion containers.
......@@ -138,8 +142,12 @@ Rel(banking_system, mainframe, "Uses")
![C4 PlantUML diagram](../img/kroki_c4_diagram.png)
<!-- vale gitlab.Spelling = NO -->
**Nomnoml**
<!-- vale gitlab.Spelling = YES -->
```plaintext
[nomnoml]
....
......@@ -159,4 +167,4 @@ Rel(banking_system, mainframe, "Uses")
....
```
![Nomnoml diagram](../img/kroki_nomnoml_diagram.png)
![Diagram](../img/kroki_nomnoml_diagram.png)
......@@ -73,7 +73,7 @@ these steps to move the logs to a new location without losing any data.
```
Use `--ignore-existing` so you don't override new job logs with older versions of the same log.
1. Unpause continuous integration data processing by editing `/etc/gitlab/gitlab.rb` and removing the `sidekiq` setting you updated earlier.
1. Resume continuous integration data processing by editing `/etc/gitlab/gitlab.rb` and removing the `sidekiq` setting you updated earlier.
1. Save the file and [reconfigure GitLab](restart_gitlab.md#omnibus-gitlab-reconfigure) for the
changes to take effect.
1. Remove the old job logs storage location:
......
......@@ -970,9 +970,13 @@ For Omnibus GitLab installations, Redis logs reside in `/var/log/gitlab/redis/`.
For Omnibus GitLab installations, Alertmanager logs reside in `/var/log/gitlab/alertmanager/`.
<!-- vale gitlab.Spelling = NO -->
## Crond Logs
For Omnibus GitLab installations, `crond` logs reside in `/var/log/gitlab/crond/`.
For Omnibus GitLab installations, crond logs reside in `/var/log/gitlab/crond/`.
<!-- vale gitlab.Spelling = YES -->
## Grafana Logs
......@@ -980,7 +984,7 @@ For Omnibus GitLab installations, Grafana logs reside in `/var/log/gitlab/grafan
## LogRotate Logs
For Omnibus GitLab installations, logrotate logs reside in `/var/log/gitlab/logrotate/`.
For Omnibus GitLab installations, `logrotate` logs reside in `/var/log/gitlab/logrotate/`.
## GitLab Monitor Logs
......@@ -1023,14 +1027,14 @@ GitLab Support often asks for one of these, and maintains the required tools.
### Briefly tail the main logs
If the bug or error is readily reproducible, save the main GitLab logs
[to a file](troubleshooting/linux_cheat_sheet.md#files--dirs) while reproducing the
[to a file](troubleshooting/linux_cheat_sheet.md#files-and-directories) while reproducing the
problem a few times:
```shell
sudo gitlab-ctl tail | tee /tmp/<case-ID-and-keywords>.log
```
Conclude the log gathering with <kbd>Ctrl</kbd> + <kbd>C</kbd>.
Conclude the log gathering with <kbd>Control</kbd> + <kbd>C</kbd>.
### GitLabSOS
......
......@@ -108,7 +108,7 @@ both primary and secondaries will fail.
### Merge requests, issues, epics
All write actions except those mentioned above will fail. So, in maintenace mode, a user cannot update merge requests, issues, etc.
All write actions except those mentioned above will fail. So, in maintenance mode, a user cannot update merge requests, issues, etc.
### Container Registry
......
......@@ -31,7 +31,7 @@ Unicorn in GitLab 14.0.
When switching to Puma, Unicorn server configuration
will _not_ carry over automatically, due to differences between the two application servers. For Omnibus-based
deployments, see [Configuring Puma Settings](https://docs.gitlab.com/omnibus/settings/puma.html#configuring-puma-settings).
For Helm based deployments, see the [Webservice Chart documentation](https://docs.gitlab.com/charts/charts/gitlab/webservice/index.html).
For Helm based deployments, see the [`webservice` chart documentation](https://docs.gitlab.com/charts/charts/gitlab/webservice/index.html).
Additionally we strongly recommend that multi-node deployments [configure their load balancers to use the readiness check](../load_balancer.md#readiness-check) due to a difference between Unicorn and Puma in how they handle connections during a restart of the service.
......
......@@ -313,13 +313,13 @@ configuration.
The different supported drivers are:
| Driver | Description |
|------------|-------------------------------------|
| filesystem | Uses a path on the local filesystem |
| Azure | Microsoft Azure Blob Storage |
| gcs | Google Cloud Storage |
| s3 | Amazon Simple Storage Service. Be sure to configure your storage bucket with the correct [S3 Permission Scopes](https://docs.docker.com/registry/storage-drivers/s3/#s3-permission-scopes). |
| swift | OpenStack Swift Object Storage |
| oss | Aliyun OSS |
|--------------|--------------------------------------|
| `filesystem` | Uses a path on the local file system |
| `Azure` | Microsoft Azure Blob Storage |
| `gcs` | Google Cloud Storage |
| `s3` | Amazon Simple Storage Service. Be sure to configure your storage bucket with the correct [S3 Permission Scopes](https://docs.docker.com/registry/storage-drivers/s3/#s3-permission-scopes). |
| `swift` | OpenStack Swift Object Storage |
| `oss` | Aliyun OSS |
Although most S3 compatible services (like [MinIO](https://min.io/)) should work with the Container Registry, we only guarantee support for AWS S3. Because we cannot assert the correctness of third-party S3 implementations, we can debug issues, but we cannot patch the registry unless an issue is reproducible against an AWS S3 bucket.
......
......@@ -35,6 +35,8 @@ The Package Registry supports the following formats:
The below table lists formats that are not supported, but are accepting Community contributions for. Consider contributing to GitLab. This [development documentation](../../development/packages.md)
guides you through the process.
<!-- vale gitlab.Spelling = NO -->
| Format | Status |
| ------ | ------ |
| Chef | [#36889](https://gitlab.com/gitlab-org/gitlab/-/issues/36889) |
......@@ -51,6 +53,8 @@ guides you through the process.
| Terraform | [WIP: Merge Request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/18834) |
| Vagrant | [#36899](https://gitlab.com/gitlab-org/gitlab/-/issues/36899) |
<!-- vale gitlab.Spelling = YES -->
## Enabling the Packages feature
NOTE:
......
......@@ -190,7 +190,7 @@ outside world.
### Additional configuration for Docker container
The GitLab Pages daemon doesn't have permissions to bind mounts when it runs
in a Docker container. To overcome this issue, you must change the chroot
in a Docker container. To overcome this issue, you must change the `chroot`
behavior:
1. Edit `/etc/gitlab/gitlab.rb`.
......@@ -236,7 +236,7 @@ control over how the Pages daemon runs and serves content in your environment.
| `gitlab_secret` | The OAuth application secret. Leave blank to automatically fill when Pages authenticates with GitLab.
| `gitlab_server` | Server to use for authentication when access control is enabled; defaults to GitLab `external_url`.
| `headers` | Specify any additional http headers that should be sent to the client with each response.
| `inplace_chroot` | On [systems that don't support bind-mounts](index.md#additional-configuration-for-docker-container), this instructs GitLab Pages to chroot into its `pages_path` directory. Some caveats exist when using inplace chroot; refer to the GitLab Pages [README](https://gitlab.com/gitlab-org/gitlab-pages/blob/master/README.md#caveats) for more information.
| `inplace_chroot` | On [systems that don't support bind-mounts](index.md#additional-configuration-for-docker-container), this instructs GitLab Pages to `chroot` into its `pages_path` directory. Some caveats exist when using in-place `chroot`; refer to the GitLab Pages [README](https://gitlab.com/gitlab-org/gitlab-pages/blob/master/README.md#caveats) for more information.
| `insecure_ciphers` | Use default list of cipher suites, may contain insecure ones like 3DES and RC4.
| `internal_gitlab_server` | Internal GitLab server address used exclusively for API requests. Useful if you want to send that traffic over an internal load balancer. Defaults to GitLab `external_url`.
| `listen_proxy` | The addresses to listen on for reverse-proxy requests. Pages binds to these addresses' network sockets and receives incoming requests from them. Sets the value of `proxy_pass` in `$nginx-dir/conf/gitlab-pages.conf`.
......@@ -538,7 +538,7 @@ the below steps to do a no downtime transfer to a new storage location.
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
1. Verify Pages are still being served up as expected.
1. Unpause Pages deployments by removing from `/etc/gitlab/gitlab.rb` the `sidekiq` setting set above.
1. Resume Pages deployments by removing from `/etc/gitlab/gitlab.rb` the `sidekiq` setting set above.
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
1. Trigger a new Pages deployment and verify it's working as expected.
1. Remove the old Pages storage location: `sudo rm -rf /var/opt/gitlab/gitlab-rails/shared/pages`
......@@ -629,7 +629,7 @@ database encryption. Proceed with caution.
on the **Pages server** and configure this share to
allow access from your main **GitLab server**.
Note that the example there is more general and
shares several sub-directories from `/home` to several `/nfs/home` mountpoints.
shares several sub-directories from `/home` to several `/nfs/home` mount points.
For our Pages-specific example here, we instead share only the
default GitLab Pages folder `/var/opt/gitlab/gitlab-rails/shared/pages`
from the **Pages server** and we mount it to `/mnt/pages`
......@@ -818,7 +818,7 @@ but commented out to help encourage others to add to it in the future. -->
### `open /etc/ssl/ca-bundle.pem: permission denied`
GitLab Pages runs inside a chroot jail, usually in a uniquely numbered directory like
GitLab Pages runs inside a `chroot` jail, usually in a uniquely numbered directory like
`/tmp/gitlab-pages-*`.
Within the jail, a bundle of trusted certificates is
......@@ -828,7 +828,7 @@ from `/opt/gitlab/embedded/ssl/certs/cacert.pem`
as part of starting up Pages.
If the permissions on the source file are incorrect (they should be `0644`), then
the file inside the chroot jail is also wrong.
the file inside the `chroot` jail is also wrong.
Pages logs errors in `/var/log/gitlab/gitlab-pages/current` like:
......@@ -837,7 +837,7 @@ x509: failed to load system roots and no roots provided
open /etc/ssl/ca-bundle.pem: permission denied
```
The use of a chroot jail makes this error misleading, as it is not
The use of a `chroot` jail makes this error misleading, as it is not
referring to `/etc/ssl` on the root filesystem.
The fix is to correct the source file permissions and restart Pages:
......@@ -862,8 +862,8 @@ open /opt/gitlab/embedded/ssl/certs/cacert.pem: no such file or directory
x509: certificate signed by unknown authority
```
The reason for those errors is that the files `resolv.conf` and `ca-bundle.pem` are missing inside the chroot.
The fix is to copy the host's `/etc/resolv.conf` and the GitLab certificate bundle inside the chroot:
The reason for those errors is that the files `resolv.conf` and `ca-bundle.pem` are missing inside the `chroot`.
The fix is to copy the host's `/etc/resolv.conf` and the GitLab certificate bundle inside the `chroot`:
```shell
sudo mkdir -p /var/opt/gitlab/gitlab-rails/shared/pages/etc/ssl
......@@ -895,7 +895,7 @@ gitlab_pages['listen_proxy'] = '127.0.0.1:8090'
### 404 error after transferring project to a different group or user
If you encounter a `404 Not Found` error a Pages site after transferring a project to
another group or user, you must trigger adomain configuration update for Pages. To do
another group or user, you must trigger a domain configuration update for Pages. To do
so, write something in the `.update` file. The Pages daemon monitors for changes to this
file, and reloads the configuration when changes occur.
......@@ -945,8 +945,8 @@ in all of your GitLab Pages instances.
### 500 error with `securecookie: failed to generate random iv` and `Failed to save the session`
This problem most likely results from an [out-dated operating system](https://docs.gitlab.com/omnibus/package-information/deprecated_os.html).
The [Pages daemon uses the `securecookie` library](https://gitlab.com/search?group_id=9970&project_id=734943&repository_ref=master&scope=blobs&search=securecookie&snippets=false) to get random strings via [crypto/rand in Go](https://golang.org/pkg/crypto/rand/#pkg-variables).
This requires the `getrandom` syscall or `/dev/urandom` to be available on the host OS.
The [Pages daemon uses the `securecookie` library](https://gitlab.com/search?group_id=9970&project_id=734943&repository_ref=master&scope=blobs&search=securecookie&snippets=false) to get random strings via [`crypto/rand` in Go](https://golang.org/pkg/crypto/rand/#pkg-variables).
This requires the `getrandom` system call or `/dev/urandom` to be available on the host OS.
Upgrading to an [officially supported operating system](https://about.gitlab.com/install/) is recommended.
### The requested scope is invalid, malformed, or unknown
......
......@@ -46,7 +46,7 @@ Each database node runs three services:
`PostgreSQL` - The database itself.
`Patroni` - Communicates with other patroni services in the cluster and handles
`Patroni` - Communicates with other Patroni services in the cluster and handles
failover when issues with the leader server occurs. The failover procedure
consists of:
......
......@@ -233,9 +233,9 @@ It can also be used as a receiving application for content encrypted with a KMS:
gcloud kms decrypt --key my-key --keyring my-test-kms --plaintext-file=- --ciphertext-file=my-file --location=us-west1 | sudo gitlab-rake gitlab:ldap:secret:write
```
**gcloud secret integration example**
**Google Cloud secret integration example**
It can also be used as a receiving application for secrets out of gcloud:
It can also be used as a receiving application for secrets out of Google Cloud:
```shell
gcloud secrets versions access latest --secret="my-test-secret" > $1 | sudo gitlab-rake gitlab:ldap:secret:write
......
......@@ -140,7 +140,7 @@ your server in `/etc/init.d/gitlab`.
---
If you are using other init systems, like systemd, you can check the
If you are using other init systems, like `systemd`, you can check the
[GitLab Recipes](https://gitlab.com/gitlab-org/gitlab-recipes/tree/master/init) repository for some unofficial services. These are
**not** officially supported so use them at your own risk.
......
......@@ -126,7 +126,7 @@ an SMTP server, but you're not seeing mail delivered. Here's how to check the se
For more advanced issues, `gdb` is a must-have tool for debugging issues.
### The GNU Project Debugger (gdb)
### The GNU Project Debugger (GDB)
To install on Ubuntu/Debian:
......@@ -140,9 +140,13 @@ On CentOS:
sudo yum install gdb
```
<!-- vale gitlab.Spelling = NO -->
### rbtrace
GitLab 11.2 ships with [rbtrace](https://github.com/tmm1/rbtrace), which
<!-- vale gitlab.Spelling = YES -->
GitLab 11.2 ships with [`rbtrace`](https://github.com/tmm1/rbtrace), which
allows you to trace Ruby code, view all running threads, take memory dumps,
and more. However, this is not enabled by default. To enable it, define the
`ENABLE_RBTRACE` variable to the environment. For example, in Omnibus:
......@@ -175,7 +179,7 @@ downtime. Otherwise skip to the next section.
1. Load the problematic URL
1. Run `sudo gdb -p <PID>` to attach to the Unicorn process.
1. In the gdb window, type:
1. In the GDB window, type:
```plaintext
call (void) rb_backtrace()
......@@ -210,7 +214,7 @@ downtime. Otherwise skip to the next section.
```
Note that if the Unicorn process terminates before you are able to run these
commands, gdb will report an error. To buy more time, you can always raise the
commands, GDB will report an error. To buy more time, you can always raise the
Unicorn timeout. For omnibus users, you can edit `/etc/gitlab/gitlab.rb` and
increase it from 60 seconds to 300:
......@@ -246,7 +250,7 @@ separate Rails process to debug the issue:
```
1. In a new window, run `top`. It should show this Ruby process using 100% CPU. Write down the PID.
1. Follow step 2 from the previous section on using gdb.
1. Follow step 2 from the previous section on using GDB.
### GitLab: API is not accessible
......@@ -279,4 +283,4 @@ The output in `/tmp/unicorn.txt` may help diagnose the root cause.
## More information
- [Debugging Stuck Ruby Processes](https://blog.newrelic.com/engineering/debugging-stuck-ruby-processes-what-to-do-before-you-kill-9/)
- [Cheatsheet of using gdb and Ruby processes](gdb-stuck-ruby.txt)
- [Cheat sheet of using GDB and Ruby processes](gdb-stuck-ruby.txt)
......@@ -55,7 +55,7 @@ chown root:git <file_or_dir>
chmod u+x <file>
```
### Files & Dirs
### Files and directories
```shell
# create a new directory and all subdirectories
......@@ -202,7 +202,7 @@ or you can build it from source if you have the Rust compiler.
First run the tool with no arguments other than the strace output filename to get
a summary of the top processes sorted by time spent actively performing tasks. You
can also sort based on total time, # of syscalls made, PID #, and # of child processes
can also sort based on total time, # of system calls made, PID #, and # of child processes
using the `-S` or `--sort` flag. The number of results defaults to 25 processes, but
can be changed using the `-c`/`--count` option. See `--help` for full details.
......@@ -220,7 +220,7 @@ Top 25 PIDs
...
```
Based on the summary, you can then view the details of syscalls made by one or more
Based on the summary, you can then view the details of system calls made by one or more
processes using the `-p`/`--pid` for a specific process, or `-s`/`--stats` flags for
a sorted list. `--stats` takes the same sorting and count options as summary.
......
......@@ -207,7 +207,7 @@ to authenticate with the API:
- [Go Proxy](../user/packages/go_proxy/index.md)
- [Maven Repository](../user/packages/maven_repository/index.md#authenticate-with-a-ci-job-token-in-maven)
- [NPM Repository](../user/packages/npm_registry/index.md#authenticate-with-a-ci-job-token)
- [Nuget Repository](../user/packages/nuget_repository/index.md)
- [NuGet Repository](../user/packages/nuget_repository/index.md)
- [PyPI Repository](../user/packages/pypi_repository/index.md#authenticate-with-a-ci-job-token)
- [Generic packages](../user/packages/generic_packages/index.md#publish-a-generic-package-by-using-cicd)
- [Get job artifacts](job_artifacts.md#get-job-artifacts)
......
......@@ -25,7 +25,7 @@ Available action types for the `action` parameter are:
- `destroyed`
- `expired`
Note that these options are downcased.
Note that these options are in lower case.
### Target Types
......@@ -39,7 +39,7 @@ Available target types for the `target_type` parameter are:
- `snippet`
- `user`
Note that these options are downcased.
Note that these options are in lower case.
### Date formatting
......
......@@ -128,7 +128,7 @@ POST /features/:name
| `user` | string | no | A GitLab username |
| `group` | string | no | A GitLab group's path, for example `gitlab-org` |
| `project` | string | no | A projects path, for example `gitlab-org/gitlab-foss` |
| `force` | boolean | no | Skip feature flag validation checks, ie. YAML definition |
| `force` | boolean | no | Skip feature flag validation checks, such as a YAML definition |
Note that you can enable or disable a feature for a `feature_group`, a `user`,
a `group`, and a `project` in a single API call.
......
......@@ -12,11 +12,15 @@ info: To determine the technical writer assigned to the Stage/Group associated w
Badges support placeholders that are replaced in real time in both the link and image URL. The allowed placeholders are:
<!-- vale gitlab.Spelling = NO -->
- **%{project_path}**: replaced by the project path.
- **%{project_id}**: replaced by the project ID.
- **%{default_branch}**: replaced by the project default branch.
- **%{commit_sha}**: replaced by the last project's commit SHA.
<!-- vale gitlab.Spelling = YES -->
Because these endpoints aren't inside a project's context, the information used to replace the placeholders comes
from the first group's project by creation date. If the group hasn't got any project the original URL with the placeholders is returned.
......
......@@ -319,7 +319,7 @@ POST /projects/:id/members
| `id` | integer/string | yes | The ID or [URL-encoded path of the project or group](README.md#namespaced-path-encoding) owned by the authenticated user |
| `user_id` | integer/string | yes | The user ID of the new member or multiple IDs separated by commas |
| `access_level` | integer | yes | A valid access level |
| `expires_at` | string | no | A date string in the format YEAR-MONTH-DAY |
| `expires_at` | string | no | A date string in the format `YEAR-MONTH-DAY` |
```shell
curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" --data "user_id=1&access_level=30" "https://gitlab.example.com/api/v4/groups/:id/members"
......@@ -357,7 +357,7 @@ PUT /projects/:id/members/:user_id
| `id` | integer/string | yes | The ID or [URL-encoded path of the project or group](README.md#namespaced-path-encoding) owned by the authenticated user |
| `user_id` | integer | yes | The user ID of the member |
| `access_level` | integer | yes | A valid access level |
| `expires_at` | string | no | A date string in the format YEAR-MONTH-DAY |
| `expires_at` | string | no | A date string in the format `YEAR-MONTH-DAY` |
```shell
curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/groups/:id/members/:user_id?access_level=40"
......
......@@ -34,7 +34,7 @@ GET /projects/:id/templates/:type
| Attribute | Type | Required | Description |
| ---------- | ------ | -------- | ----------- |
| `id` | integer / string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) |
| `type` | string | yes| The type `(dockerfiles|gitignores|gitlab_ci_ymls|licenses|issues|merge_requests)` of the template |
| `type` | string | yes | The type `(dockerfiles|gitignores|gitlab_ci_ymls|licenses|issues|merge_requests)` of the template |
Example response (licenses):
......
......@@ -71,7 +71,7 @@ Below are the changes made between V3 and V4.
- Notes do not return deprecated field `upvote` and `downvote` [!9384](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/9384)
- Return HTTP status code `400` for all validation errors when creating or updating a member instead of sometimes `422` error. [!9523](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/9523)
- Remove `GET /groups/owned`. Use `GET /groups?owned=true` instead [!9505](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/9505)
- Return 202 with JSON body on async removals on V4 API (`DELETE /projects/:id/repository/merged_branches` and `DELETE /projects/:id`) [!9449](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/9449)
- Return 202 with JSON body on asynchronous removals on V4 API (`DELETE /projects/:id/repository/merged_branches` and `DELETE /projects/:id`) [!9449](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/9449)
- `GET /projects/:id/milestones?iid[]=x&iid[]=y` array filter has been renamed to `iids` [!9096](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/9096)
- Return basic information about pipeline in `GET /projects/:id/pipelines` [!8875](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/8875)
- Renamed all `build` references to `job` [!9463](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/9463)
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment