Please use this project as an example to learn from, about making automation by CI/CD not to use as a reference to creating the latest APTOS blockchain node. Basis for starting working with the CI/CD automation intended to go to production. APTOS blockchain may get upgrade so the repository code will not support the latest node code.
1- This /.gitlab-ci.yaml/ template allows you to automate creation of a container. For this template I used Rancher. After running this template you will be
able to deploy the container. Once deployment finished successfully you can see the logs and monitor it by the Rancher.
You can pass environment variables from one job to another job in a later stage through variable inheritance. These variables cannot be used as CI/CD variables to configure a pipeline, but they can be used in job scripts.
CI_COMMIT_SHAvariable means: The commit revision for which project is built- I am using this
$CI_COMMIT_SHORT_SHAvariable intodocker-composewhich means: The first eight characters ofCI_COMMIT_SHA. By this I wanted to useCI_COMMIT_SHORT_SHAas part of directory name which were later pushed to the server by rsync. It should have returned short hash from current commit. $CI_JOB_NAMEtargets the job that need to be run by this config file.CI_JOB_TOKEN: Token used for authenticating with GitLab Container Registry, downloading dependent repositories, authenticate with multi-project pipelines when triggers are involved, and for downloading job artifacts.$CI_REGISTRY: I will return by this the address of GitLab's Container Registry.$CI_REGISTRY_IMAGE: With GitLab, you can add a job to your pipeline to build Docker images, and push them to the built-in container registry. You can set to use previous image as a cache to speedup build process.$CI_PROJECT_DIR: The full path where the repository is cloned and where the job is run.
More info can be found in docs/predefined/CI/CD variables.