Comparison of GitHub Actions with competitors
Deep dive into workflow syntax, triggers, and job configuration
Explore matrices, reusable workflows, and composite actions
•Runner Types and Execution Environments
•Persisting Build Outputs with Artifacts
•Controlling GitHub Permissions
•Authenticating to Third-Party Systems
•Matrix Strategies, Conditionals, and Concurrency Controls
Discover and integrate community actions from the GitHub Marketplace
Build custom JavaScript and Docker actions from scratch
•JavaScript and TypeScript Actions
Optimize logs, secrets, environments, and permissions for teams
•Developer Experience (Actions)
Harden workflows with security, reliability, and cost-saving techniques
•Maintainable Workflow Patterns
Apply course concepts by automating a real-world deployment pipeline
Workflow commands are the strings that influence the runner (e.g., ::error::
,
::notice::
, writing to $GITHUB_OUTPUT
, etc.). When authoring JavaScript/TypeScript
actions, you can use ergonomic wrappers such as core.error()
and
core.setOutput()
. In Bash or other languages you must emit the raw strings
yourself:
Documentation: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-commands
Equivalent ways to surface an error annotation:
# JavaScript/Typescript
core.error('missing semicolon', {file: 'app.js', startLine: 12})
# bash
echo '::error file=app.js,line=12::missing semicolon'
Other commonly used commands include:
::group::
/ ::endgroup::
to collapse log sections.::debug::message
to surface debug logs when ACTIONS_STEP_DEBUG
is
enabled.GITHUB_ENV
,
GITHUB_OUTPUT
, or GITHUB_STATE
environment variables.Understanding these primitives is essential when you need to communicate between steps, fail gracefully, or annotate build output.