|author||Harald Pfeiffer <harald.pfeiffer _ xmart.de>||2018-06-28 17:22:48 +0200|
|committer||Harald Pfeiffer <harald.pfeiffer _ xmart.de>||2018-06-28 17:22:48 +0200|
Further correction of stuff Gitlab gracefully ignored
1 files changed, 3 insertions, 0 deletions
@@ -8,17 +8,20 @@ explicitly push the code with which I administer my git folders.
### Rough Outline
What the repository does in its rough state can be outlined as:
1. Be jenkins without jenkins :) Most environments lack automated frameworks to check code and configuration quality for system administrators. Praise Gitlab's CI runner and the sysadmins who make this available in *your* environment. We are using this, a forked docker image will be supplied with all necessary patches and then checks your code inside there.
2. Check our main Makefile if there's additional stuff inside. For now there isn't ;)
### Content / In-Deep
* **filelistgen** Scans the whole GITROOT for files to be checked/linted during QoS (see .gitlab.-ci.yml)
* **\*-list** The generated lists for the code checkers/linters, see *filelistgen*
* **\*-checker** Additional code checker/linter scripts if not directly defined in *.gitlab-ci.yml*
#### Main directory:
* ***Makefile*** which prepares everything for the docker image (parser file lists etc). You could also use this inside the docker image, just add a point to the gitlab YAML. We do not do this inside the CI runner docker as most environments (see rough outline) can be happy enough to have the runners at all and we don't want to push unnecessary FLOPS and IOPS inside there.
* ***.gitlab-ci.yml*** - Gitlab YAML to trigger all CI runner checks, including all of the above plus a Makefile checker for the root directory's Makefile
* ***samples*** - Directory containing simple samples to check whether all automatization works