change trunk and production branches
This commit is contained in:
+4
-4
@@ -91,8 +91,8 @@ publish:
|
|||||||
services:
|
services:
|
||||||
- docker:25-dind
|
- docker:25-dind
|
||||||
only:
|
only:
|
||||||
- develop
|
- main
|
||||||
- master
|
- production
|
||||||
script:
|
script:
|
||||||
- docker info
|
- docker info
|
||||||
- docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
|
- docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
|
||||||
@@ -103,7 +103,7 @@ deploy:dev:
|
|||||||
image: docker:25-cli
|
image: docker:25-cli
|
||||||
stage: deploy
|
stage: deploy
|
||||||
only:
|
only:
|
||||||
- develop
|
- main
|
||||||
environment:
|
environment:
|
||||||
name: dev
|
name: dev
|
||||||
url: http://api.dev.sahkoinsinoorikilta.fi
|
url: http://api.dev.sahkoinsinoorikilta.fi
|
||||||
@@ -125,7 +125,7 @@ deploy:production:
|
|||||||
stage: deploy
|
stage: deploy
|
||||||
image: docker:25-cli
|
image: docker:25-cli
|
||||||
only:
|
only:
|
||||||
- master
|
- production
|
||||||
environment:
|
environment:
|
||||||
name: production
|
name: production
|
||||||
url: https://api.sahkoinsinoorikilta.fi
|
url: https://api.sahkoinsinoorikilta.fi
|
||||||
|
|||||||
@@ -15,7 +15,6 @@ Set up your SSH key authentication in GitLab Profile Settings. Then clone the re
|
|||||||
```bash
|
```bash
|
||||||
git clone git@gitlab.com:sahkoinsinoorikilta/vtmk/web2.0-backend.git
|
git clone git@gitlab.com:sahkoinsinoorikilta/vtmk/web2.0-backend.git
|
||||||
cd web2.0-backend
|
cd web2.0-backend
|
||||||
git checkout develop
|
|
||||||
```
|
```
|
||||||
|
|
||||||
Copy env file for local use:
|
Copy env file for local use:
|
||||||
@@ -109,11 +108,11 @@ Example of creating a feature branch:
|
|||||||
git checkout -b feature-branch-name
|
git checkout -b feature-branch-name
|
||||||
```
|
```
|
||||||
|
|
||||||
When your changes are ready and the code works without errors, submit a merge request to `develop` in GitLab. Another developer reviews your changes and runs the merge. Feature branches should be closed on merge.
|
When your changes are ready and the code works without errors, submit a merge request to `main` in GitLab. Another developer reviews your changes and runs the merge. Feature branches should be closed on merge.
|
||||||
|
|
||||||
Bugfixes do not need their own feature branches and can be pushed straight to `develop`, but if the fix needs a notable amount of work, it should be done in a `bugfix` branch instead.
|
Bugfixes do not need their own feature branches and can be pushed straight to `main`, but if the fix needs a notable amount of work, it should be done in a `bugfix` branch instead.
|
||||||
|
|
||||||
Merge requests to `master` should be reviewed by multiple developers. Only a moderator can accept merge requests to `master`.
|
Merge requests to `main` should be reviewed by multiple developers. Only a moderator can accept merge requests to `production`.
|
||||||
|
|
||||||
### Linting
|
### Linting
|
||||||
|
|
||||||
@@ -153,4 +152,4 @@ For more information about deployment check **[infra](https://gitlab.com/sahkoin
|
|||||||
|
|
||||||
## GitLab CI
|
## GitLab CI
|
||||||
|
|
||||||
All pushed changes go through the GitLab Continuous Integration, which consists of automated unit testing and linting. Make sure your changes pass both before merging to `develop` or `master`.
|
All pushed changes go through the GitLab Continuous Integration, which consists of automated unit testing and linting. Make sure your changes pass both before merging to `main` or `production`.
|
||||||
|
|||||||
Reference in New Issue
Block a user