Source code¶
GitLab is used to host all the CSI projects under different groups based on the use case.
ICS Control System Infrastructure group¶
The ics-infrastructure group is the default group for the CSI team. This is where a project should go except if it fits in one of the following groups.
rpms¶
Subgroup to gather projects to build RPMs. Mostly used for kernel modules. See How to install kernel modules or introduce a new kernel module.
ICS Ansible Galaxy¶
The ics-ansible-galaxy group shall be used for all Ansible roles and playbooks.
A webhook is defined at the group level to watch changes in that group and send events to the galaxy-bot.
ICS Cookiecutter¶
The ics-cookiecutter group isn’t CSI specific. Gathering all cookiecutter templates under the same group makes them easier to discover.
This group includes the templates for Ansible roles and playbooks.
ICS Docker¶
The ics-docker group shall be used for generic docker images. GitLab is used as a container registry.
Having repositories under that group allows to use the same path for all generic images: registry.esss.lu.se/ics-docker/<application>. For example:
registry.esss.lu.se/ics-docker/awx
registry.esss.lu.se/ics-docker/centos-systemd
registry.esss.lu.se/ics-docker/miniconda
New projects can be created using the ICS docker cookiecutter template.
It includes the following .gitlab-ci.yml:
---
include:
- remote: "https://gitlab.esss.lu.se/ics-infrastructure/gitlab-ci-yml/raw/master/Docker.gitlab-ci.yml"
When pushing changes, the image is built and pushed with the branch name as tag. When pushing a git tag, it is used
as image tag and latest is updated to point to it.
See the Docker.gitlab-ci.yml template for details.
Note
If you are developing an application, like CSEntry, this project should be under the ics-infrastructure group instead, even if it includes a docker image.
ICS RPMs¶
The ics-rpms group was moved under the ics-infrastructure group and renamed rpms.
Ansible inventory¶
The ansible-inventory group is used to store Ansible inventories in GitLab, like the cceco-inventory used to deploy CCECO applications.
CSEntry is our main inventory. There are some use cases where having the inventory in GitLab makes sense.
Conda Recipes¶
The conda-recipes group gathers various conda recipes, like p4p-recipe or ca-gateway.
It also includes recipes used by E3, but not specific to E3, like libusb-recipe.
E3 recipes¶
The e3-recipes group gathers all conda recipes for E3.
The epics-base-recipe isn’t only used for E3. It’s used to build and deploy the CA Gateway and PVA Gateway.
A webhook is defined at the group level to watch changes in that group and send events to the conda-bot. Note that another webhook is defined in the epics-modules group to trigger MR in the corresponding conda recipe when pushing a tag to a module.
Conda EEE recipes¶
The conda-eee-recipes group was used to test conda packaging for EEE. It’s not used anymore.
Jupyter¶
The jupyter group gathers Jupyter Notebooks that can be accessed from JupyterHub via the jupyterlab-gitlab extension.