Commit 43b8046e authored by Marcel Amirault's avatar Marcel Amirault

Merge branch 'docs-replace-master-default-configure-1' into 'master'

Docs: Replaces master with main or default branch (Configure)

See merge request gitlab-org/gitlab!64231
parents 275079fd 2892a511
......@@ -33,7 +33,7 @@ to the job:
When executed, ChatOps looks up the specified job name and attempts to match it
to a corresponding job in [`.gitlab-ci.yml`](../yaml/README.md). If a matching job
is found on `master`, a pipeline containing only that job is scheduled. After the
is found on the default branch, a pipeline containing only that job is scheduled. After the
job completes:
- If the job completes in *less than 30 minutes*, the ChatOps sends the job's output to Slack.
......
......@@ -155,7 +155,7 @@ these steps to enable Auto DevOps if it's disabled:
1. Navigate to **Settings > CI/CD > Auto DevOps**, and click **Expand**.
1. Select **Default to Auto DevOps pipeline** to display more options.
1. In **Deployment strategy**, select your desired [continuous deployment strategy](index.md#deployment-strategy)
to deploy the application to production after the pipeline successfully runs on the `master` branch.
to deploy the application to production after the pipeline successfully runs on the default branch.
1. Click **Save changes**.
![Auto DevOps settings](img/guide_enable_autodevops_v12_3.png)
......@@ -199,7 +199,7 @@ The jobs are separated into stages:
licenses and is allowed to fail
([Auto License Compliance](stages.md#auto-license-compliance)) **(ULTIMATE)**
- **Review** - Pipelines on `master` include this stage with a `dast_environment_deploy` job.
- **Review** - Pipelines on the default branch include this stage with a `dast_environment_deploy` job.
To learn more, see [Dynamic Application Security Testing (DAST)](../../user/application_security/dast/index.md).
- **Production** - After the tests and checks finish, the application deploys in
......@@ -208,7 +208,7 @@ The jobs are separated into stages:
- **Performance** - Performance tests are run on the deployed application
([Auto Browser Performance Testing](stages.md#auto-browser-performance-testing)). **(PREMIUM)**
- **Cleanup** - Pipelines on `master` include this stage with a `stop_dast_environment` job.
- **Cleanup** - Pipelines on the default branch include this stage with a `stop_dast_environment` job.
After running a pipeline, you should view your deployed website and learn how
to monitor it.
......@@ -267,7 +267,7 @@ you should next create a feature branch to add content to your application:
After submitting the merge request, GitLab runs your pipeline, and all the jobs
in it, as [described previously](#deploy-the-application), in addition to
a few more that run only on branches other than `master`.
a few more that run only on branches other than the default branch.
![Merge request](img/guide_merge_request_v12_3.png)
......@@ -303,7 +303,7 @@ the **View app** **{external-link}** button to see your changes deployed.
![Review app](img/guide_merge_request_review_app_v12_3.png)
After merging the merge request, GitLab runs the pipeline on the `master` branch,
After merging the merge request, GitLab runs the pipeline on the default branch,
and then deploys the application to production.
## Conclusion
......
......@@ -350,8 +350,7 @@ Any load performance test result differences between the source and target branc
Auto Deploy is an optional step for Auto DevOps. If the [requirements](requirements.md) are not met, the job is skipped.
After a branch or merge request is merged into the project's default branch (usually
`master`), Auto Deploy deploys the application to a `production` environment in
After a branch or merge request is merged into the project's default branch, Auto Deploy deploys the application to a `production` environment in
the Kubernetes cluster, with a namespace based on the project name and unique
project ID, such as `project-4321`.
......
......@@ -195,7 +195,7 @@ higher*. This is the
remove the variables, or rename the variables temporarily to
`XDB_INITIALIZE` or the `XDB_MIGRATE` to effectively disable them.
1. Run a new CI pipeline for the branch. In this case, we run a new CI
pipeline for `master`.
pipeline for `main`.
1. After the pipeline is successful, your application is upgraded
with the new PostgreSQL installed. Zero replicas exist at this time, so
no traffic is served for your application (to prevent
......@@ -250,5 +250,5 @@ steps to reinstate your application:
removed or disabled.
1. Restore the `PRODUCTION_REPLICAS` or `REPLICAS` variable to its original value.
1. Run a new CI pipeline for the branch. In this case, we run a new CI
pipeline for `master`. After the pipeline is successful, your
pipeline for `main`. After the pipeline is successful, your
application should be serving traffic as before.
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