Define workflow and standards in CONTRIBUTING.md
1. Clone the project: `git clone email@example.com:chakra/websites/melange.git` 2. Create feature branch for your feature: `git checkout -b $feature_name` 3. Write code. Commit changes: `git commit -am "My feature is ready"` 4. Push your branch to GitLab: `git push origin $feature_name` 5. Review your code on commits page. 6. Create a merge request. **(When does/should the CI kick in?)** 7. Your team lead will review the code & merge it into the `master` branch. 8. On merge into the `master` branch, the images are built, tagged as `latest` and deployed to the staging environment. 9. On tags, the staging images are tagged as `$CI_COMMIT_TAG` and deployed to the production environment. Add [release notes](https://docs.gitlab.com/ee/workflow/releases.html), and use [semantic versioning](https://semver.org/).
Emphasis mine. I want the forks to have CI enabled automatically to run the first test stage at the time of writing:
stages: - test source - build images - test images - release - deploy # Job 1 flake8: except: - tags stage: test source image: python:3.7.2 before_script: - pip install flake8 script: - flake8 . # Job 2 pylint: except: - tags stage: test source image: python:3.7.2 before_script: - pip install pylint script: - find -name '*.py' -not -path "./venv/*" -not -path "./*/migrations/*" | xargs pylint -j 0 --rcfile=.pylintrc | tee pylint.log || exit 0 # Job 3 unit test: except: - tags stage: test source image: python:3.7.2 services: - postgres:11.2 variables: SECRET_KEY: $TEST_SECRET_KEY before_script: - pip install pipenv - pipenv install --system script: - python manage.py test
Note that the current behavior is subject to change. In the usual contribution flow, external contributors follow the following steps:
- Fork a parent project.
- Create a merge request from the forked project that targets the
masterbranch in the parent project.
- A pipeline runs on the merge request.
- A maintainer from the parent project checks the pipeline result, and merge into a target branch if the latest pipeline has passed.
Currently, those pipelines are created in a forked project, not in the parent project. This means you cannot completely trust the pipeline result, because, technically, external contributors can disguise their pipeline results by tweaking their GitLab Runner in the forked project.
There are multiple reasons about why GitLab doesn't allow those pipelines to be created in the parent project, but one of the biggest reasons is security concern. External users could steal secret variables from the parent project by modifying
.gitlab-ci.yml, which could be some sort of credentials. This should not happen.
We're discussing a secure solution of running pipelines for merge requests that submitted from forked projects, see the issue about the permission extension.