Common Workflows

In this module we explore some common workflow types and sketch out how to approach them.

Linting and Static Analysis

A minimal lint workflow only needs to:

1. Check out the repository code.
2. Install the linting tool (or rely on a container that has it baked in).
3. Run the linter across the code base.

You can provide a much better experience with a few enhancements:

• Determine which files changed so only the relevant subsets of the code base are linted.
• Cache tool downloads or dependency installs to avoid paying the setup cost on every run.
• Surface the results in the GitHub UI via job summaries, pull request comments, or status checks.

Marketplace actions often save you from wiring up all of that logic by hand. GitHub's super-linter bundles dozens of linters and automatically scopes work to the files changed in the workflow run.

The same pattern applies to other static analysis tools—check out the code, install the tool, run it, and then iterate on optimizations such as caching, incremental execution, or richer reporting.

Testing Applications

Testing workflows look similar to linting but introduce dependency management and artifact handling. A baseline pipeline:

1. Checks out the repository code.
2. Installs the language runtime and package manager.
3. Restores dependencies.
4. Runs the test suite.

Improvements include caching dependencies, uploading test reports for later inspection, and publishing coverage metrics. Marketplace actions like actions/setup-node or actions/setup-python handle installing language toolchains and wiring up built-in dependency caching.

Building Artifacts

Build workflows extend the testing pipeline by producing deployable outputs. After checking out code and installing prerequisites, run the build command and publish the result to a package registry, artifact store, or release asset. Common post-build steps include attaching SBOMs, generating provenance attestations, or running container image scanning.

When building containers, swap out the language toolchain for a container builder such as Docker, BuildKit, or docker/build-push-action. After the image is produced, push it to your registry of choice and optionally sign it with cosign or a similar tool.

Deploying Applications

Most deployment workflows start where the build leaves off—using the packaged artifact and promoting it into an environment.

Push-Based Deployments

Push-based delivery runs deployment tooling directly from the workflow. Typical steps include checking out deployment manifests, installing CLIs like kubectl, Helm, or Terraform, authenticating to the target platform (preferably through OIDC), executing the deploy command, and verifying health checks.

GitOps Deployments

GitOps shifts the final deploy step to an agent running in your environment. The workflow updates configuration stored in Git—often Helm charts or Kustomize manifests—commits the version bump, and lets Argo CD, Flux, or a similar controller synchronize the change.

Beyond CI/CD, GitHub Actions can keep your repository organized.

Release Management

Tools like google-github-actions/release-please-action inspect commits, apply semantic versioning rules, update changelogs, and cut releases.

Managing Stale Issues and Pull Requests

Scheduled workflows can label, comment on, and close inactive issues to keep backlogs manageable. The actions/stale action handles the bookkeeping with only a few lines of YAML.

Dependency Updates

Automations like Dependabot or Renovate periodically check your manifest files for outdated dependencies, raise pull requests with the updates, and rely on your test workflows to validate them. For custom package managers, you can script this yourself: check out the repo, query for newer versions, update manifests, push a branch, and open a PR through the REST or GraphQL API.

GitHub Provided Workflow Templates

If you are unsure where to start, GitHub offers curated templates under Actions → New workflow.

The suggestions are based on the languages and frameworks detected in your repository and provide a minimal but functional pipeline for tasks such as building Docker images or deploying to AWS Elastic Container Service. Use them for inspiration, then iterate with better authentication patterns (for example, swapping long-lived cloud credentials for OIDC federation), improved caching, and organization-specific conventions.