Commit 0466372d authored by Achilleas Pipinellis's avatar Achilleas Pipinellis Committed by Russell Dickenson

Rename master to main in the release group docs

parent f98d4700
...@@ -69,7 +69,7 @@ staging: ...@@ -69,7 +69,7 @@ staging:
- gem install dpl - gem install dpl
- dpl --provider=heroku --app=my-app-staging --api_key=$HEROKU_STAGING_API_KEY - dpl --provider=heroku --app=my-app-staging --api_key=$HEROKU_STAGING_API_KEY
only: only:
- master - main
``` ```
The first line `apt-get update -yq` updates the list of available packages, The first line `apt-get update -yq` updates the list of available packages,
...@@ -81,7 +81,7 @@ The above example is valid for all Debian-compatible systems. ...@@ -81,7 +81,7 @@ The above example is valid for all Debian-compatible systems.
It's pretty common in the development workflow to have staging (development) and It's pretty common in the development workflow to have staging (development) and
production environments production environments
Let's consider the following example: we would like to deploy the `master` Let's consider the following example: we would like to deploy the `main`
branch to `staging` and all tags to the `production` environment. branch to `staging` and all tags to the `production` environment.
The final `.gitlab-ci.yml` for that setup would look like this: The final `.gitlab-ci.yml` for that setup would look like this:
...@@ -92,7 +92,7 @@ staging: ...@@ -92,7 +92,7 @@ staging:
- gem install dpl - gem install dpl
- dpl --provider=heroku --app=my-app-staging --api_key=$HEROKU_STAGING_API_KEY - dpl --provider=heroku --app=my-app-staging --api_key=$HEROKU_STAGING_API_KEY
only: only:
- master - main
production: production:
stage: deploy stage: deploy
...@@ -105,7 +105,7 @@ production: ...@@ -105,7 +105,7 @@ production:
We created two deploy jobs that are executed on different events: We created two deploy jobs that are executed on different events:
- `staging`: Executed for all commits pushed to the `master` branch - `staging`: Executed for all commits pushed to the `main` branch
- `production`: Executed for all pushed tags - `production`: Executed for all pushed tags
We also use two secure variables: We also use two secure variables:
......
...@@ -118,7 +118,7 @@ pages: ...@@ -118,7 +118,7 @@ pages:
paths: paths:
- public - public
only: only:
- master - main
``` ```
### `.gitlab-ci.yml` for a static site generator ### `.gitlab-ci.yml` for a static site generator
...@@ -133,7 +133,7 @@ the `pages` job with the [`only` parameter](../../../ci/yaml/index.md#only--exce ...@@ -133,7 +133,7 @@ the `pages` job with the [`only` parameter](../../../ci/yaml/index.md#only--exce
whenever a new commit is pushed to a branch used specifically for your whenever a new commit is pushed to a branch used specifically for your
pages. pages.
That way, you can have your project's code in the `master` branch and use an That way, you can have your project's code in the `main` branch and use an
orphan branch (let's name it `pages`) to host your static generator site. orphan branch (let's name it `pages`) to host your static generator site.
You can create a new empty branch like this: You can create a new empty branch like this:
...@@ -163,7 +163,7 @@ pages: ...@@ -163,7 +163,7 @@ pages:
- pages - pages
``` ```
See an example that has different files in the [`master` branch](https://gitlab.com/pages/jekyll-branched/tree/master) See an example that has different files in the [`main` branch](https://gitlab.com/pages/jekyll-branched/tree/main)
and the source files for Jekyll are in a [`pages` branch](https://gitlab.com/pages/jekyll-branched/tree/pages) which and the source files for Jekyll are in a [`pages` branch](https://gitlab.com/pages/jekyll-branched/tree/pages) which
also includes `.gitlab-ci.yml`. also includes `.gitlab-ci.yml`.
......
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