Service Documentation Guidelines


Here you can find basics about Markdown, instructions for installing MkDocs, Service Documentation environment in gitlab and examples of the relevant web servers defined in EOS, which seems to be a simple-enough option for static documentation sites.

This is a proposal about CERN/IT-CDA Documentation strategy, discussed with CDA section managers between 2018-08-22 and 2018-10-31. Conclusions reached thanks to our group discussions on Documentation status.

Technical steps needed to write Service Pages in Markdown

  1. About MkDocs: Very basic steps follow but a more complete document is available from . To download MkDocs from here. MkDocs is recommended due to the uncertain GitBook future, as an Open Source product. The advantage of having mkdocs locally is that you can check your edits via http://localhost:8000/ before you publish. If you use MkDocs all .md files should be under a directory called docs. Also, the list of contents of your site (shown on the left banner) and its colours should be entered in the file called mkdocs.yml. If a .md file exists but is linked from nowhere, http://localhost:8000/ will claim that the page doesn't exist. To install and "serve" your work:
    sudo pip install mkdocs
    sudo pip install mkdocs-material
    sudo pip install --upgrade mkdocs (if needed...)
    sudo pip install --upgrade mkdocs-materials (if needed...)
    mkdocs serve (go to  the local directory that contains the files of your site before you launch this command)
  2. Use your preferred editor, e.g. Atom or Visual Studio Code.
  3. Create a gitlab repository where the Service Pages of Your_Service will live. Here is a boilerplate setup to Fork (see button on top banner) and rename (see how) to . Example: NB! As soon as you create your project, go to Settings->General->Advanced (Expand)->Remove fork relationship! Else, your updates will go to the original boilerplate!!
  4. To deploy the gitlab repository with the Markdown ( documentation in it, one needs to:
    • create a service account with access to some EOS folder (in the EOS workspace dir, like indico or in the EOS project dir, like elearning) which should host a corresponding web site, e.g. docs-Your_Service. For OpenShift to host the web server instructions here

Markdown basics to write pages:

--- Horizontal line OR two empty lines = New slide
## Header 2 (H1 is reserved for post titles) 
### Header 3 
#### Header 4 
A link to [Jekyll Now]( 
Video insert: <iframe width="576" height="360" frameborder="0" src="" allowfullscreen></iframe> 
An image, located within /images; ![an image alt text](/images/image-filename.png "an image title") 
* A bulletted list 
- alternative syntax 1 
+ alternative syntax 2  
  - an indented list item
_italics_ - 
**bold** - 
More on Markdown in and

Gitlab notes to publish pages:

The Indico Service example - end-user documentation:

To edit your pages locally:

  1. Make a local folder to clone the site
  2. Clone the published version from gitlab to this local folder (requires CERN login). To do this, type: git clone The SSH option is better so that you don't login every time... You have to enter your key in gitlab.
  3. Open local folder docs-Your_Service with your preferred editor and enter content in individual

To publish in gitlab:

  1. save (local in editor)
  2. stage (local in project)
  3. define new branch name from within your editor (branching is optional but recommeded, especially if there are several co-authors).
  4. commit (with a msg)
  5. push (branch name will be created at the gitlab destination project, if it doesn't exist)
  6. review your changes via URI<_yourbranchname_>/<_path-to-the-page-you-edited>. This is possible IF your .gitlab-ci.yml, the file that takes care of the site building and publishing rules, has this option enabled. See an example here or here.
  7. create a merge request, if happy with the changes. To CHECK publishing activity, click on the gitlab pipelines (left banner CI/CD link). NB! You have to configure the project to merge into the master of your and not the original boilerpoint from where you forked.

Restricting a sub-directory in Gitlab

Input by Iago Pardo & Thomas Baron:

  • About the repository in Git, if the project is set as public, a sub-directory inside this project will always be public.

### Control access to the site adding the following file in EOS .htaccess

#Header unset ETag
Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate"
Header set Pragma "no-cache"
Header set Expires "Wed, 11 Jan 1984 05:00:00 GMT"

SSLRequireSSL # The modules only work using HTTPS
AuthType shibboleth
ShibRequireSession On
ShibRequireAll On
ShibExportAssertion Off

Require valid-user
Require ADFS_GROUP "<your admin e-group>"

Adding this file into the subdirectory will only be accessible for the members of the e-group.

Example: results into which should be public can be seen by authorised Gitlab users in this project but the resulting should only be seen by the it-dep-cda e-group.

-- MariaDimou - 2018-05-02

Edit | Attach | Watch | Print version | History: r25 < r24 < r23 < r22 < r21 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r25 - 2019-04-04 - MariaDimou
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Edutech All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback