When several people change the same project, one person's edit can break another person's work. Continuous integration runs shared build and test checks automatically so the team finds those problems while the change is still small.

A service such as GitHub Actions runs jobs described in the repository. A useful first pipeline installs the declared dependencies, runs meaningful checks and produces the application package. Give each job a clear failure result and keep the code revision with the output so you can tell which change produced it.

Try it in a lab

Design a minimal pipeline for a small repository: install locked dependencies, run meaningful checks and produce a build artifact. Introduce a failing test and confirm that later release steps do not run.

Check your understanding

Identify which revision produced the artifact, which credentials each job receives and how a reviewer can reproduce the failure locally.

Before you start

Pull requests from untrusted contributors must not receive privileged release credentials. Pin dependencies and review actions that execute third-party code. In GitHub Actions, pin third-party actions to full commit SHAs; release tags can move.

Read the official guide

Use the project documentation for version-specific commands and prerequisites. Record the versions and results of your own exercise. This page proposes a learning activity; it does not report a Kubedex test.

This is a newly written study reference at an address from the original Kubedex course outline. The original lesson was not recovered. It does not include course enrolment, progress tracking or a certificate.

Sources & further reading

  1. Primary learning documentation
  2. GitHub Actions secure use and immutable action pins

Spotted something that needs another look?

Help improve this page →