Git

Gitea, users etc.

Admin user: gitea-admin, password netcicd, role: admins

Log in as gitea-admin, go to: site administration -> user accounts and for the accounts listed below, change the authentication source to keycloak and set the Authentication sign-in name to the username

Organisation: InfraAutomators Teams (password is username):

• gitea-netops-read with user: thedude
• gitea-netops-write with user: thespecialist
• gitea-netdev-read with user: architect
• gitea-netdev-write with user: networkguru
• gitea-tooling-read with user: hacker (password whitehat)
• gitea-tooling-write with user: tooltiger

Repository: NetCICD, NetCICD-developer-toolchain

The OpenID link between Gitea and Keycloak works, but the roles are not extracted from the JWT. This is why the users are linked to the teams in Gitea. A new version of Gitea should fix this.

You can use any user present in Keycloak to log in, however you need to add the user to an organization and team manually using the gitea-admin user.

Git governance

There is little overlap in knowledge when looking at the different teams in infrastructure. Moreover, the automation scripts each infrastructure platform team puts into git contains sensitive information other teams should probably not have access to. This is why you'd want to use different organisations in git.

Within each organisation, there can be multiple teams, such as security, datacenter and campus in networking. Or server, VM and container in compute.

How to use git

In order to start using the CICD-toolbox, you need to know how to use git. On this page a short introduction is given on how the Git can be used to achieve the goals described.

The first step is to understand the git workflow. As git is a revision control system, it makes it easy to work in a structured manner. Git distinguises a few important concepts:

• Production code is in a branch called "Master" and production code is released in so-called releases. This makes it possible to guarantee that production code always works. For more info, see this post.
• When new code is developed, it is in a so-called "branch". Each developer has his own branch. As you can see from the image below, individual contributions are first created in separated branches, then merged into "Develop" and from "Develop" into "Master".

In order to start working on a new feature, you follow the following sequence

1. Clone the repository you want to work on:

   $ git clone https://github.com/Devoteam/NetCICD.git

2. Switch to the a feature branch off of the develop branch:

   $ git checkout -b myfeature develop
Switched to a new branch "myfeature"

3. Do your thing and test locally

4. If you want to save intermediate versions, commit them locally with:

   $ git add . $ git commit -m "What have you changed and why"

   with

   $ git status

   before and after the the add, you can see what you have changed and if all changes are tracked.

5. When you are done, you push your changes to the git server to share them with your peers:

   $ git push origin myfeature

   again, use

   $ git status

   to validate that your local version is identical to the version on the server.

6. The NetCICD Toolbox is configured with something called a "webhook". This means that if you push to the server, Jenkins is made aware of it and starts testing your contribution. The result of the test is added as comment to your commit on the server.

   When the test is succesful, Jenkins creates a "pull-request" for your contribution to be incorporated into the "Develop" branch.

   You should not be able to merge yourself: even though you are brilliant, it is always wise to let some other poor soul validate your gem :)