GitLab CI/CD
GitLab's built-in continuous integration and continuous delivery platform, which configures pipelines, stages, and jobs through .gitlab-ci.yml. It supports execution by Runners, transfer of build artifacts, and collection of test reports.
Timeline (last 90 days)
Reusable CI/CD checking habits include: writing business rules as tests (especially thresholds), using the commit ID to find the corresponding run, explaining failures or successes from job logs, and confirming that the running service used the package from that build.
The core concepts of GitLab CI/CD include Pipeline (the entire run), Stage (a grouping of jobs), and Job (the specific commands).
GitLab Runner is the agent process that actually executes CI/CD jobs; jobs defined in a Pipeline are ultimately picked up and executed by some Runner.
In the demonstrated GitLab CI/CD pipeline, after a faulty version was pushed, pipeline number 66 failed, and after the test job failed, the packaging and deployment jobs were skipped.
In the demonstration, after the fix, pushing a new commit created pipeline number 67, and all three jobs (test, package, deploy) succeeded.
In the failed test log in the demonstration, the case that exactly reached the threshold expected a shipping fee of 0 cents but actually returned 1000 cents, thereby exposing a bug of overcharging 10 yuan.
In the demonstration, by computing the JAR's fingerprint and verifying the running file's fingerprint after deployment, it was confirmed that the running service used the package built in this run, rather than an old version or a cached file.
In the demonstrated pipeline configuration, the test job invokes Maven's Test, includes the short commit ID as the build version in the version parameter, and checks the exit code to ensure failure propagation.
CI_JOB_TOKEN is a short-lived token automatically injected into each job in a GitLab CI/CD pipeline, and it becomes invalid once the job ends.
All Facts (9)
In the demonstration, by computing the JAR's fingerprint and verifying the running file's fingerprint after deployment, it was confirmed that the running service used the package built in this run, rather than an old version or a cached file.
50%UnverifiedThe core concepts of GitLab CI/CD include Pipeline (the entire run), Stage (a grouping of jobs), and Job (the specific commands).
50%UnverifiedGitLab Runner is the agent process that actually executes CI/CD jobs; jobs defined in a Pipeline are ultimately picked up and executed by some Runner.
50%UnverifiedReusable CI/CD checking habits include: writing business rules as tests (especially thresholds), using the commit ID to find the corresponding run, explaining failures or successes from job logs, and confirming that the running service used the package from that build.
50%UnverifiedIn the demonstrated pipeline configuration, the test job invokes Maven's Test, includes the short commit ID as the build version in the version parameter, and checks the exit code to ensure failure propagation.
50%UnverifiedIn the failed test log in the demonstration, the case that exactly reached the threshold expected a shipping fee of 0 cents but actually returned 1000 cents, thereby exposing a bug of overcharging 10 yuan.
50%UnverifiedCI_JOB_TOKEN is a short-lived token automatically injected into each job in a GitLab CI/CD pipeline, and it becomes invalid once the job ends.
50%UnverifiedIn the demonstration, after the fix, pushing a new commit created pipeline number 67, and all three jobs (test, package, deploy) succeeded.
50%UnverifiedIn the demonstrated GitLab CI/CD pipeline, after a faulty version was pushed, pipeline number 66 failed, and after the test job failed, the packaging and deployment jobs were skipped.
50%