Introduction
Understanding organizationsUnderstanding componentsManage organizationsManage componentsManage component Jira integrations
Set up your first organizationUnderstanding users and teamsUnderstanding role-based access controlManage usersManage teamsConfigure role-based access controlRBAC permissions reference
Understanding authentication in CloudBees UnifySet up multifactor authenticationConfigure SAML single sign-onConfigure OIDC authenticationConfigure network security policiesNetwork security reference
Understanding platform configurationUnderstanding environmentsManage properties and secretsManage environmentsTrack environment inventoryConfigure containersSet up preconfigured actionsConfigure notificationsSet up Slack webhook notifications
Accessibility policy referenceShared responsibility model referenceSubscription and services agreementSupport policiesSupported browsers and external tools
Introduction
Understanding feature managementUnderstanding Configuration as CodeGet started with feature managementCreate and manage feature flagsConfigure feature flag targetingOrganize feature flagsImplement feature flag governanceConfiguration as Code reference
Understanding flag impressions and activity statusUnderstanding flag healthUnderstanding code referencesReview and clean up feature flagsSet up code references
Understanding Jira integration for feature flagsSet up the Jira integrationLink Jira tickets to feature flags
Understanding multiple SDK keysBuild your first mobile app with feature flagsBuild your first feature-flagged web applicationBuild your first feature-flagged backend serviceInstall client-side SDKsInstall server-side SDKsConfigure multiple SDK keysMobile SDK referenceWeb SDK referenceBackend SDK referenceClient SDK referenceFlag implementation reference
Introduction
Understanding CI workflowsUnderstanding custom actionsCreate a build workflowCreate a custom actionCreate and manage workflowsCreate reusable workflowsTest and validate containers in workflowsCheck out source codeTrigger workflows remotelyWorkflow syntax referenceJobs syntax referenceSteps syntax referenceServices syntax reference
Monitor workflow runsView test results in runsView evidence in runsView deployments in runsManage workflow artifactsPublish test resultsPublish evidence itemsGenerate a software bill of materialsManage ServiceNow change requests
Configure workflow credentialsConfigure AWS credentialsConfigure container registry credentialsConfigure Git credentialsIntegrate CyberArk Conjur secrets
Understanding GitHub Actions integrationSet up GitHub Actions integrationDisplay GitHub Actions workflows and runsRegister GHA build artifactsPublish GHA deployed artifactsPublish GHA test resultsPublish GHA evidence itemsTrigger CloudBees workflows from GitHub ActionsScan with GitHub Actions
Understanding CloudBees CI and Jenkins® integrationConnect CI and Jenkins controllersMonitor CI and Jenkins buildsRegister CI build artifactsRegister CI deployed artifactsPublish CI test resultsConfigure CI security scanningCI and Jenkins integration reference
Build and publish container imagesUnderstanding external CI/CD integrationsRun external CI/CD jobsExternal CI/CD action reference
Introduction
Understanding release orchestrationManage applicationsCreate deployer workflowsCreate staged workflowsCreate and manage releasesOrchestrate multi-workflow releasesRelease management reference
Understanding artifact managementRegister and track artifactsStore and retrieve artifactsPromote artifactsGenerate a software bill of materialsArtifact management reference
Deploy with HelmDeploy to KubernetesContainer deployment reference
Deploy to AWSAWS deployment reference
Deploy with enterprise platformsExecute remote deployment commandsEnterprise deployment reference
Verify deployments with New RelicDeployment verification reference

Understanding custom actions

2 minute read

Custom actions are reusable, self-contained units of automation that you package in a Git repository and invoke from any CloudBees Unify workflow. Understanding how custom actions are structured and executed helps you decide when to write one, how to scope it, and how to make it accessible to the teams that need it.

What is a custom action?

A custom action combines two things: a Git repository containing an action.yml file, and one or more Docker container images that execute the action’s steps. The action.yml file defines the action’s name, inputs, outputs, and the steps to run. The Docker image provides the execution environment, including the language runtime, tools, and dependencies the steps need.

Actions are language-agnostic. You can write action steps in any language, such as shell, Go, Python, or Java, as long as the Docker image you specify contains the necessary runtime.

Diagram showing the flow from source code through Docker image and action.yml to workflow invocation and outputs
Figure 1. How a custom action is built and invoked

Action scope and access

Whether your action’s repository and Docker image need to be public or private depends on who needs to use the action.

Public actions

If you want your action to be usable by anyone on CloudBees Unify, both the Git repository and the Docker image it depends on must be publicly accessible. Any public container registry, for example Docker Hub, works for public actions.

Private actions

If your action is intended only for use within your CloudBees Unify organization, the repository and Docker images can remain private. To grant CloudBees Unify access to a private repository, configure Git credentials. For private container images, CloudBees Unify supports configuring an Amazon Elastic Container Registry (ECR) integration for authenticating to your private ECR registry. CloudBees Unify does not support private registries hosted on any other cloud provider.

How actions are resolved

When a workflow step invokes a custom action using uses, CloudBees Unify resolves the action repository based on the reference format:

GitHub shorthand

org/repo@ref resolves from github.com. For example, cloudbees-io/checkout@v1 resolves to github.com/cloudbees-io/checkout at the v1 tag.

Full URL

Actions hosted on GitLab, Bitbucket, Gerrit, or any other supported SCM require a full URL: https://gitlab.com/<project>/<repo>@<ref>;.

Default branch

Omitting the ref causes CloudBees Unify to resolve the action from the main branch. Specifying a ref, such as a tag, branch, or commit SHA, is strongly recommended to prevent unexpected changes from affecting your workflows.

Context variables in actions

The full range of CloudBees Unify context variables is available inside action step definitions. In addition, actions support the action.scm.sha variable in the uses field of their steps. This variable resolves to the commit SHA of the repository being referenced in the workflow step that invoked the action.

Understanding CI workflows
Create a build workflow