Fix markdown spacing in various docs
Align images and lists in assorted markdown docs
This commit is contained in:
Marcel Amirault
Achilleas Pipinellis
parent
74efd580bd
commit
f751748d38
14 changed files with 108 additions and 103 deletions
|
|
@ -52,7 +52,7 @@ section.
|
|||
**Admin Area > Users**. You will find the option of the access level under
|
||||
the 'Access' section.
|
||||
|
||||
|
||||
|
||||
|
||||
1. Click **Save changes** or **Create user** for the changes to take effect.
|
||||
|
||||
|
|
|
|||
|
|
@ -378,8 +378,8 @@ Here's what happens behind the scenes:
|
|||
1. `script` is executed.
|
||||
1. `after_script` is executed.
|
||||
1. `cache` runs and the `vendor/` directory is zipped into `cache.zip`.
|
||||
This file is then saved in the directory based on the
|
||||
[Runner's setting](#where-the-caches-are-stored) and the `cache: key`.
|
||||
This file is then saved in the directory based on the
|
||||
[Runner's setting](#where-the-caches-are-stored) and the `cache: key`.
|
||||
1. `job B` runs.
|
||||
1. The cache is extracted (if found).
|
||||
1. `before_script` is executed.
|
||||
|
|
@ -520,7 +520,7 @@ via GitLab's UI:
|
|||
1. Navigate to your project's **CI/CD > Pipelines** page.
|
||||
1. Click on the **Clear Runner caches** button to clean up the cache.
|
||||
|
||||
|
||||
|
||||
|
||||
1. On the next push, your CI/CD job will use a new cache.
|
||||
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ To use GitLab CI/CD with a Bitbucket Cloud repository:
|
|||
Passwords** to authenticate the build status script setting commit build
|
||||
statuses in Bitbucket. Repository write permissions are required.
|
||||
|
||||
|
||||
|
||||
|
||||
1. In GitLab, from **Settings > CI/CD > Environment variables**, add variables to allow
|
||||
communication with Bitbucket via the Bitbucket API:
|
||||
|
|
|
|||
|
|
@ -19,12 +19,12 @@ administrator:
|
|||
1. In GitLab create a **CI/CD for external repo** project and select
|
||||
**GitHub**.
|
||||
|
||||
|
||||
|
||||
|
||||
1. Once authenticated, you will be redirected to a list of your repositories to
|
||||
connect. Click **Connect** to select the repository.
|
||||
|
||||
|
||||
|
||||
|
||||
1. In GitHub, add a `.gitlab-ci.yml` to [configure GitLab CI/CD](../quick_start/README.md).
|
||||
|
||||
|
|
@ -55,14 +55,14 @@ repositories:
|
|||
Token**. This token with be used to access your repository and push commit
|
||||
statuses to GitHub.
|
||||
|
||||
The `repo` and `admin:repo_hook` should be enable to allow GitLab access to
|
||||
your project, update commit statuses, and create a web hook to notify
|
||||
GitLab of new commits.
|
||||
The `repo` and `admin:repo_hook` should be enable to allow GitLab access to
|
||||
your project, update commit statuses, and create a web hook to notify
|
||||
GitLab of new commits.
|
||||
|
||||
1. In GitLab create a **CI/CD for external repo** project and select
|
||||
**GitHub**.
|
||||
|
||||
|
||||
|
||||
|
||||
1. Paste the token into the **Personal access token** field and click **List
|
||||
Repositories**. Click **Connect** to select the repository.
|
||||
|
|
@ -86,21 +86,21 @@ your repository:
|
|||
Access Token.** GitLab will use this token to access your repository and
|
||||
push commit statuses.
|
||||
|
||||
Enter a **Token description** and update the scope to allow:
|
||||
Enter a **Token description** and update the scope to allow:
|
||||
|
||||
`repo` so that GitLab can access your project and update commit statuses
|
||||
`repo` so that GitLab can access your project and update commit statuses
|
||||
|
||||
1. In GitLab create a **CI/CD project** using the Git URL option and the HTTPS
|
||||
URL for your GitHub repository. If your project is private, use the personal
|
||||
access token you just created for authentication.
|
||||
|
||||
GitLab will automatically configure polling-based pull mirroring.
|
||||
GitLab will automatically configure polling-based pull mirroring.
|
||||
|
||||
1. Still in GitLab, enable the [GitHub project integration](../../user/project/integrations/github.md)
|
||||
from **Settings > Integrations.**
|
||||
|
||||
Check the **Active** checkbox to enable the integration, paste your
|
||||
personal access token and HTTPS repository URL into the form, and **Save.**
|
||||
Check the **Active** checkbox to enable the integration, paste your
|
||||
personal access token and HTTPS repository URL into the form, and **Save.**
|
||||
|
||||
1. Still in GitLab create a **Personal Access Token** with `API` scope to
|
||||
authenticate the GitHub web hook notifying GitLab of new commits.
|
||||
|
|
@ -108,15 +108,15 @@ your repository:
|
|||
1. In GitHub from **Settings > Webhooks** create a web hook to notify GitLab of
|
||||
new commits.
|
||||
|
||||
The web hook URL should be set to the GitLab API to
|
||||
[trigger pull mirroring](../../api/projects.md#start-the-pull-mirroring-process-for-a-project-starter),
|
||||
using the GitLab personal access token we just created.
|
||||
The web hook URL should be set to the GitLab API to
|
||||
[trigger pull mirroring](../../api/projects.md#start-the-pull-mirroring-process-for-a-project-starter),
|
||||
using the GitLab personal access token we just created.
|
||||
|
||||
```
|
||||
https://gitlab.com/api/v4/projects/<NAMESPACE>%2F<PROJECT>/mirror/pull?private_token=<PERSONAL_ACCESS_TOKEN>
|
||||
```
|
||||
```
|
||||
https://gitlab.com/api/v4/projects/<NAMESPACE>%2F<PROJECT>/mirror/pull?private_token=<PERSONAL_ACCESS_TOKEN>
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
1. In GitHub add a `.gitlab-ci.yml` to configure GitLab CI/CD.
|
||||
|
||||
|
|
|
|||
|
|
@ -418,10 +418,14 @@ fully understand [IAM Best Practices in AWS](https://docs.aws.amazon.com/IAM/lat
|
|||
|
||||
1. Log into your AWS account and go to the [Security Credentials page](https://console.aws.amazon.com/iam/home#/security_credential)
|
||||
1. Click the **Access Keys** section and **Create New Access Key**. Create the key and keep the id and secret around, you'll need them later
|
||||
|
||||
|
||||
|
||||
|
||||
1. Go to your GitLab project, click **Settings > CI/CD** on the left sidebar
|
||||
1. Expand the **Variables** section
|
||||
|
||||
|
||||
|
||||
|
||||
1. Add a key named `AWS_KEY_ID` and copy the key id from Step 2 into the **Value** textbox
|
||||
1. Add a key named `AWS_KEY_SECRET` and copy the key secret from Step 2 into the **Value** textbox
|
||||
|
||||
|
|
|
|||
|
|
@ -147,11 +147,11 @@ Once you have the route mapping set up, it will take effect in the following loc
|
|||
|
||||
- In the diff for a merge request, comparison, or commit.
|
||||
|
||||
|
||||
|
||||
|
||||
- In the blob file view.
|
||||
|
||||
|
||||
|
||||
|
||||
## Visual Reviews **(STARTER)**
|
||||
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ You can only register a shared Runner if you are an admin of the GitLab instance
|
|||
|
||||
1. Grab the shared-Runner token on the `admin/runners` page
|
||||
|
||||
|
||||
|
||||
|
||||
1. [Register the Runner][register]
|
||||
|
||||
|
|
@ -373,12 +373,12 @@ attacker.
|
|||
|
||||
To reset the token:
|
||||
|
||||
1. Go to **Settings > CI/CD** for a specified Project
|
||||
1. Expand the **General pipelines settings** section
|
||||
1. Find the **Runner token** form field and click the **Reveal value** button
|
||||
1. Delete the value and save the form
|
||||
1. Go to **Settings > CI/CD** for a specified Project.
|
||||
1. Expand the **General pipelines settings** section.
|
||||
1. Find the **Runner token** form field and click the **Reveal value** button.
|
||||
1. Delete the value and save the form.
|
||||
1. After the page is refreshed, expand the **Runners settings** section
|
||||
and check the registration token - it should be changed
|
||||
and check the registration token - it should be changed.
|
||||
|
||||
From now on the old token is not valid anymore and will not allow to register
|
||||
a new Runner to the project. If you are using any tools to provision and
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ To enable the Facebook OmniAuth provider you must register your application with
|
|||
|
||||
1. Enter the address of your GitLab installation at the bottom of the package
|
||||
|
||||
|
||||
|
||||
|
||||
1. Choose "Next"
|
||||
|
||||
|
|
@ -29,7 +29,7 @@ To enable the Facebook OmniAuth provider you must register your application with
|
|||
|
||||
1. Fill in a contact email for your app
|
||||
|
||||
|
||||
|
||||
|
||||
1. Choose "Save Changes"
|
||||
|
||||
|
|
@ -45,7 +45,7 @@ To enable the Facebook OmniAuth provider you must register your application with
|
|||
|
||||
1. You should now see an app key and app secret (see screenshot). Keep this page open as you continue configuration.
|
||||
|
||||
|
||||
|
||||
|
||||
1. On your GitLab server, open the configuration file.
|
||||
|
||||
|
|
|
|||
|
|
@ -43,67 +43,68 @@ There are no special requirements if you are using GitLab.com.
|
|||
|
||||
1. In GitLab, create a new application in order to allow Jira to connect with your GitLab account
|
||||
|
||||
While logged-in, go to `Settings -> Applications`. (Click your profile avatar at
|
||||
the top right, choose `Settings`, and then navigate to `Applications` from the left
|
||||
navigation menu.) Use the form to create a new application.
|
||||
While logged-in, go to `Settings -> Applications`. (Click your profile avatar at
|
||||
the top right, choose `Settings`, and then navigate to `Applications` from the left
|
||||
navigation menu.) Use the form to create a new application.
|
||||
|
||||
Enter a useful name for the `Name` field.
|
||||
Enter a useful name for the `Name` field.
|
||||
|
||||
For the `Redirect URI` field, enter `https://<your-gitlab-instance-domain>/login/oauth/callback`,
|
||||
replacing `<your-gitlab-instance-domain>` appropriately. So for example, if you are using GitLab.com,
|
||||
this would be `https://gitlab.com/login/oauth/callback`.
|
||||
For the `Redirect URI` field, enter `https://<your-gitlab-instance-domain>/login/oauth/callback`,
|
||||
replacing `<your-gitlab-instance-domain>` appropriately. So for example, if you are using GitLab.com,
|
||||
this would be `https://gitlab.com/login/oauth/callback`.
|
||||
|
||||
NOTE: **Note**:
|
||||
If using a GitLab version earlier than 11.3 the `Redirect URI` value should be `https://<your-gitlab-instance-domain>/-/jira/login/oauth/callback`.
|
||||
NOTE: **Note**:
|
||||
If using a GitLab version earlier than 11.3 the `Redirect URI` value should be `https://<your-gitlab-instance-domain>/-/jira/login/oauth/callback`.
|
||||
|
||||
|
||||
- Check `api` in the Scopes section.
|
||||
|
||||
|
||||
- Check `api` in the Scopes section.
|
||||
|
||||
1. Click `Save application`. You will see the generated 'Application Id' and 'Secret' values.
|
||||
Copy these values that you will use on the Jira configuration side.
|
||||
Copy these values that you will use on the Jira configuration side.
|
||||
|
||||
## Jira Configuration
|
||||
|
||||
1. In Jira, from the gear menu at the top right, go to `Applications`. Navigate to `DVCS accounts`
|
||||
from the left navigation menu. Click `Link GitHub account` to start creating a new integration.
|
||||
(We are pretending to be GitHub in this integration until there is further platform support from Jira.)
|
||||
from the left navigation menu. Click `Link GitHub account` to start creating a new integration.
|
||||
(We are pretending to be GitHub in this integration until there is further platform support from Jira.)
|
||||
|
||||
|
||||
|
||||
|
||||
1. Complete the form
|
||||
|
||||
Select GitHub Enterprise for the `Host` field.
|
||||
Select GitHub Enterprise for the `Host` field.
|
||||
|
||||
For the `Team or User Account` field, enter the relative path of a top-level GitLab group that you have access to,
|
||||
or the relative path of your personal namespace.
|
||||
For the `Team or User Account` field, enter the relative path of a top-level GitLab group that you have access to,
|
||||
or the relative path of your personal namespace.
|
||||
|
||||
|
||||
|
||||
|
||||
For the `Host URL` field, enter `https://<your-gitlab-instance-domain>/`,
|
||||
replacing `<your-gitlab-instance-domain>` appropriately. So for example, if you are using GitLab.com,
|
||||
this would be `https://gitlab.com/`.
|
||||
For the `Host URL` field, enter `https://<your-gitlab-instance-domain>/`,
|
||||
replacing `<your-gitlab-instance-domain>` appropriately. So for example, if you are using GitLab.com,
|
||||
this would be `https://gitlab.com/`.
|
||||
|
||||
NOTE: **Note**:
|
||||
If using a GitLab version earlier than 11.3 the `Host URL` value should be `https://<your-gitlab-instance-domain>/-/jira`
|
||||
NOTE: **Note**:
|
||||
If using a GitLab version earlier than 11.3 the `Host URL` value should be `https://<your-gitlab-instance-domain>/-/jira`
|
||||
|
||||
For the `Client ID` field, use the `Application ID` value from the previous section.
|
||||
For the `Client ID` field, use the `Application ID` value from the previous section.
|
||||
|
||||
For the `Client Secret` field, use the `Secret` value from the previous section.
|
||||
For the `Client Secret` field, use the `Secret` value from the previous section.
|
||||
|
||||
Ensure that the rest of the checkboxes are checked.
|
||||
Ensure that the rest of the checkboxes are checked.
|
||||
|
||||
1. Click `Add` to complete and create the integration.
|
||||
|
||||
Jira takes up to a few minutes to know about (import behind the scenes) all the commits and branches
|
||||
for all the projects in the GitLab group you specified in the previous step. These are refreshed
|
||||
every 60 minutes.
|
||||
Jira takes up to a few minutes to know about (import behind the scenes) all the commits and branches
|
||||
for all the projects in the GitLab group you specified in the previous step. These are refreshed
|
||||
every 60 minutes.
|
||||
|
||||
> **Note:**
|
||||
> In the future, we plan on implementating real-time integration. If you need
|
||||
> to refresh the data manually, you can do this from the `Applications -> DVCS
|
||||
> accounts` screen where you initially set up the integration:
|
||||
>
|
||||
> 
|
||||
> **Note:**
|
||||
> In the future, we plan on implementating real-time integration. If you need
|
||||
> to refresh the data manually, you can do this from the `Applications -> DVCS
|
||||
> accounts` screen where you initially set up the integration:
|
||||
>
|
||||
> 
|
||||
|
||||
To connect additional GitLab projects from other GitLab top-level groups (or personal namespaces), repeat the above
|
||||
steps with additional Jira DVCS accounts.
|
||||
|
|
|
|||
|
|
@ -19,12 +19,12 @@ at their primary email address.
|
|||
1. Go to the admin area using the wrench icon in the top right corner and
|
||||
navigate to **Overview > Users > Send email to users**.
|
||||
|
||||
|
||||
|
||||
|
||||
1. Compose an email and choose where it will be sent (all users or users of a
|
||||
chosen group or project):
|
||||
|
||||
|
||||
|
||||
|
||||
## Unsubscribing from emails
|
||||
|
||||
|
|
|
|||
|
|
@ -38,13 +38,13 @@ those projects provide a barebones application built on some well-known framewor
|
|||
Rails, Spring, or NodeJS Express project. For this example,
|
||||
we'll use the Ruby on Rails template.
|
||||
|
||||
|
||||
|
||||
|
||||
1. Give your project a name, optionally a description, and make it public so that
|
||||
you can take advantage of the features available in the
|
||||
[GitLab Gold plan](https://about.gitlab.com/pricing/#gitlab-com).
|
||||
|
||||
|
||||
|
||||
|
||||
1. Click **Create project**.
|
||||
|
||||
|
|
@ -56,20 +56,20 @@ under which this application will be deployed.
|
|||
1. On the project's landing page, click the button labeled **Add Kubernetes cluster**
|
||||
(note that this option is also available when you navigate to **Operations > Kubernetes**).
|
||||
|
||||
|
||||
|
||||
|
||||
1. Choose **Create on Google Kubernetes Engine**.
|
||||
|
||||
|
||||
|
||||
|
||||
1. Sign in with Google.
|
||||
|
||||
|
||||
|
||||
|
||||
1. Connect with your Google account and press **Allow** when asked (this will
|
||||
be shown only the first time you connect GitLab with your Google account).
|
||||
|
||||
|
||||
|
||||
|
||||
1. The last step is to fill in the cluster details. Give it a name, leave the
|
||||
environment scope as is, and choose the GCP project under which the cluster
|
||||
|
|
@ -80,7 +80,7 @@ under which this application will be deployed.
|
|||
cluster will be created, enter the number of nodes you want it to have, and
|
||||
finally choose their [machine type](https://cloud.google.com/compute/docs/machine-types).
|
||||
|
||||
|
||||
|
||||
|
||||
1. Once ready, click **Create Kubernetes cluster**.
|
||||
|
||||
|
|
@ -133,7 +133,7 @@ Now that the Kubernetes cluster is set up and ready, let's enable Auto DevOps.
|
|||
successfully runs on the `master` branch.
|
||||
1. Click **Save changes**.
|
||||
|
||||
|
||||
|
||||
|
||||
Once you complete all the above and save your changes, a new pipeline is
|
||||
automatically created. To view the pipeline, go to **CI/CD > Pipelines**.
|
||||
|
|
@ -201,7 +201,7 @@ applications. In the rightmost column for the production environment, you can ma
|
|||
Prometheus collects data about the Kubernetes cluster and how the application
|
||||
affects it (in terms of memory/CPU usage, latency, etc.).
|
||||
|
||||
|
||||
|
||||
|
||||
- The third icon is the [web terminal](../../ci/environments.md#web-terminals)
|
||||
and it will open a terminal session right inside the container where the
|
||||
|
|
|
|||
|
|
@ -30,22 +30,22 @@ Otherwise, you can:
|
|||
|
||||
1. Navigate manually to the **Admin Area** by clicking the wrench icon in the menu bar.
|
||||
|
||||
|
||||
|
||||
|
||||
1. And then going to the **License** tab and click on **Upload New License**.
|
||||
|
||||
|
||||
|
||||
|
||||
1. If you've received a `.gitlab-license` file, you should have already downloaded
|
||||
it in your local machine. You can then upload it directly by choosing the
|
||||
license file and clicking the **Upload license** button. In the image below,
|
||||
you can see that the selected license file is named `GitLab.gitlab-license`.
|
||||
|
||||
|
||||
|
||||
|
||||
If you've received your license as plain text, you need to select the
|
||||
"Enter license key" option, copy the license, paste it into the "License key"
|
||||
field and click **Upload license**.
|
||||
If you've received your license as plain text, you need to select the
|
||||
"Enter license key" option, copy the license, paste it into the "License key"
|
||||
field and click **Upload license**.
|
||||
|
||||
## Add your license at install time
|
||||
|
||||
|
|
|
|||
|
|
@ -107,18 +107,18 @@ In order to purchase additional minutes, you should follow these steps:
|
|||
|
||||
1. Go to **Group > Settings > Pipelines quota**. Once you are on that page, click on **Buy additional minutes**.
|
||||
|
||||
|
||||
|
||||
|
||||
1. Locate the subscription card that is linked to your group on GitLab.com,
|
||||
click on **Buy more CI minutes**, and complete the details about the transaction.
|
||||
|
||||
|
||||
|
||||
|
||||
1. Once we have processed your payment, the extra CI minutes
|
||||
will be synced to your Group and you can visualize it from the
|
||||
**Group > Settings > Pipelines quota** page:
|
||||
|
||||
|
||||
|
||||
|
||||
Be aware that:
|
||||
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ higher can also edit a comment made by someone else.
|
|||
You can also reply to a comment notification email to reply to the comment if
|
||||
[Reply by email] is configured for your GitLab instance. Replying to a standard comment
|
||||
creates another standard comment. Replying to a threaded comment creates a reply in the thread. Email replies support
|
||||
[Markdown] and [quick actions], just as if you replied from the web.
|
||||
[Markdown] and [quick actions], just as if you replied from the web.
|
||||
|
||||
## Resolvable comments and threads
|
||||
|
||||
|
|
@ -58,17 +58,17 @@ To create a commit diff thread:
|
|||
1. Navigate to the merge request **Commits** tab. A list of commits that
|
||||
constitute the merge request will be shown.
|
||||
|
||||
|
||||
|
||||
|
||||
1. Navigate to a specific commit, click on the **Changes** tab (where you
|
||||
will only be presented diffs from the selected commit), and leave a comment.
|
||||
|
||||
|
||||
|
||||
|
||||
1. Any threads created this way will be shown in the merge request's
|
||||
**Discussions** tab and are resolvable.
|
||||
|
||||
|
||||
|
||||
|
||||
Threads created this way will only appear in the original merge request
|
||||
and not when navigating to that commit under your project's
|
||||
|
|
@ -343,8 +343,8 @@ bottom of the screen with two buttons:
|
|||
|
||||
- **Discard**: Discards all comments that have not been submitted.
|
||||
- **Finish review**: Opens a list of comments ready to be submitted for review.
|
||||
Clicking **Submit review** will publish all comments. Any quick actions
|
||||
submitted are performed at this time.
|
||||
Clicking **Submit review** will publish all comments. Any quick actions
|
||||
submitted are performed at this time.
|
||||
|
||||
Alternatively, every pending comment has a button to finish the entire review.
|
||||
|
||||
|
|
@ -389,18 +389,18 @@ the Merge Request authored by the user that applied them.
|
|||
1. Choose a line of code to be changed, add a new comment, then click
|
||||
on the **Insert suggestion** icon in the toolbar:
|
||||
|
||||
|
||||
|
||||
|
||||
1. In the comment, add your suggestion to the pre-populated code block:
|
||||
|
||||
|
||||
|
||||
|
||||
1. Click **Comment**.
|
||||
|
||||
The suggestions in the comment can be applied by the merge request author
|
||||
directly from the merge request:
|
||||
The suggestions in the comment can be applied by the merge request author
|
||||
directly from the merge request:
|
||||
|
||||
|
||||
|
||||
|
||||
Once the author applies a suggestion, it will be marked with the **Applied** label,
|
||||
the thread will be automatically resolved, and GitLab will create a new commit
|
||||
|
|
|
|||
Loading…
Reference in a new issue