Workflow for users
If you are user and you don’t find a security topic you are interested in, you can add that topic to the backlog.
In this case follow steps 1.
to 4.
.
After you submit a topic, someone will start working on it.
This person will reach out to you, if they need any clarification regarding your issue.
Workflow for topic contributors
As a topic contributor, you will either use the full workflow described below, in case you are the person coming up with security topic and writing content.
If you will be working on an existing issue from backlog, then you should follow steps 5.
to 9.
.
Full workflow
The general flow for contributing to CI/CD Security repository is:
-
Choose a topic to work on based on Introduction section (or from issue backlog)
-
Check if similar issue already exist; if not open a new issue in Gitlab
-
Write issue in form of a User Story:
As a .... I want to .... so that ....
-
Assign your self to the issue; label the issue with one of the key area tags and press Submit.
-
Open merge request (MR) using
Create merge request
button (this will automatically create branch with issue number and title as branch name e.g. 1-example-issue)
-
After MR is opened, assign yourself to the MR and tag it with
Doing
tag. -
Write a solution, a guide or a topic to markdown file(s) under subdirectory of
content/
directory. To make content uniform, please use the template below with the predefined sections.--- title: "Title of the new topic " # date when content was last modified lastmod: 2020-08-19T15:48:21+02:00 weight: 1 draft: false # search related keywords keywords: ["keywords", "related", "to", "your", "topic"] --- ### Security problem _Write here about security problem/dilema you are trying to address._ ### Security control proposal _Write here about possible solutions to a problem/dilema stated above._ ### Reference implementation _Add here a relevant implementation from reference documentation, but make sure it's security compliant. Sometimes reference documentation implementations are not secure, with security being addressed in a footnote._ ### Practical implementation _Add here a practical implementation that is self contained. Make sure you are not sharing any private or confidential information._
-
Request a review from one of the reviewers by tagging them in merge request comments or adding them as an assignee to the issue (Reviewers: Miroslav Bagľaš)
-
After review and changes, reviewer will merge branch to master. The resulting git history will look like this:
Contributing small changes such as fixes, typos
If you spot a typo or some other error, that would not be considered fundamental
change to the existing topic, you can skip the step 3. from the general flow.
Label such issue as fix
and