Context

The OpsChain context framework provides a read only set of values. These values enable you to reuse code between projects, environments and assets, conditionally performing logic based on when and where the step is being performed.

After reading this guide you should understand:

• the information available in the OpsChain context
• how to access the OpsChain context values in your actions

OpsChain context

Within each action, OpsChain context values are available via OpsChain.context (which will behave like a Hashie Mash). The OpsChain.context includes the following information:

Context key	Description
parents	The project, environment and asset the step is running under, keyed by type - see parents below1
parent_order	The names of the property owners that contributed to the step's properties, least specific first - see parent order below
change	The change the currently running step belongs to, including its metadata, the action requested, the Git remote and revision it was run from, and its current status1
step	The currently running step, including its action, full path, input arguments and current status1
user	Information about the user who submitted the change name - the user who submitted the change groups - an array of LDAP groups that the user is a member of
git_remotes	The project's Git remotes the git_clone resource may check out, as controlled by git_remote.mountable Credentials are never included
api_key	The short lived API key the query and send_email keywords authenticate with - see API key below
template	The asset template the asset was created from1
template_version	The asset template version the change is running, including the git_rev and commit_sha the change resolved to, whether the version follows its Git revision, and why it last failed to do so1
mintmodel	The asset's concretised MintModel

The template, template_version and mintmodel keys are only present when the change is running on an asset. mintmodel is nil when the asset template does not include a MintModel.

Parents

OpsChain.context.parents is keyed by the type of each node the step is running under - project, environment and asset - and always includes the node the change was run on. A change run on an environment therefore has a project and an environment, while a change run on an asset also has an asset.

require 'opschain'

action :report_target do
  log.info "Deploying to #{OpsChain.context.parents.environment.name} in #{OpsChain.context.parents.project.name}"
end

Test for a key's presence rather than assuming it exists, so the same code can be run at more than one level of your project hierarchy:

require 'opschain'

action :report_target do
  log.info "Running on asset #{OpsChain.context.parents.asset.code}" if OpsChain.context.parents.key?('asset')
end

Parent order

OpsChain.context.parent_order lists the property owners that contributed to the step's properties, from the least specific to the most specific. The last entry is change, reflecting that any change properties are applied last.

parent_order:
  - project
  - environment
  - change

A change running on an asset also includes the asset, the asset template it was created from, and the asset template version it is running. Properties assigned to the template apply to every asset created from it, and are overridden in turn by the template version and then the asset itself:

parent_order:
  - project
  - environment
  - template
  - template_version
  - asset
  - change

The same names can be supplied to OpsChain.properties_for to read a single owner's properties rather than the merged set.

API key

OpsChain.context.api_key is a short lived API key scoped to the running change. The query and send_email keywords use it automatically, so you rarely need to read it yourself.

OpsChain issues a key for every change, so no configuration is required to use query or send_email from your actions. The key carries the permissions of the user who created the change, and is revoked as soon as the change finishes - it cannot be used to reach the API once the change is no longer running.

Accessing the context information

Context information can be accessed using dot or square bracket notation with string or symbol keys. These examples are equivalent:

require 'opschain'

OpsChain.context.change.action
OpsChain.context[:change][:action]
OpsChain.context['change']['action']

note

The OpsChain.context structure is read only.

Example usage

In the example below, running the main action in the development environment will set the OpsChain logger to the DEBUG level. When running in any other environment, the OpsChain logger will remain in the default (INFO) level.

require 'opschain'

action :enable_logging do
  log.level = ::Logger::DEBUG if OpsChain.context.parents.environment.code == 'dev'
end

action main: ['enable_logging'] do
  .... main process
end

Sample context values

Below is an example of the values available to an action via OpsChain.context (formatted as YAML):

---
change:
  id: 3a97c789-8f4e-497c-a1aa-04efaa2e87e7
  created_by: mary
  step_name: deploy
  action: deploy
  build_without_cache: false
  auto_continue_wait_steps: false
  initial_step_tree: {}
  metadata:
    custom:
      change: metadata
  scheduled: false
  approved_by: []
  rejected_by: []
  cancelled_by:
  state_timing:
    running:
      ended_at:
      started_at: '2026-08-14T06:48:37.147101Z'
  state_timing_summary: {}
  notify: {}
  skip_steps: []
  starting_step:
  status_code: running
  created_at: '2020-05-20T10:00:00.000000Z'
  started_at: '2020-05-20T10:00:05.000000Z'
  finished_at:
  updated_at: '2026-08-14T06:48:37.360685Z'
  asset_name:
  environment_name: Receivables
  project_name: Finance
  git_remote_name: origin
  git_rev: bug-fix
  commit_sha: 5213c76dad01ac0d87c2c900d46778675d4dc760
  requires_approval_from:
step:
  id: 37fdf12f-aff3-4134-8926-a2321cef5acf
  approved_by: []
  rejected_by: []
  continued_by: []
  requires_approval_from:
  action: deploy
  change_id: 3a97c789-8f4e-497c-a1aa-04efaa2e87e7
  child_execution_strategy: sequential
  full_path: deploy
  ignore_failure: false
  input_arguments: []
  state_timing:
    running:
      ended_at:
      started_at: '2026-08-14T06:48:37.147101Z'
  step_sequence: 1
  step_type: standard
  description:
  step_name: deploy
  skip_requested: false
  created_at: '2020-05-20T10:00:00.000000Z'
  started_at: '2020-05-20T10:00:05.000000Z'
  finished_at:
  updated_at: '2026-08-14T06:48:37.360685Z'
  status_code: running
git_remotes:
- id: '019fff07-9ca1-7c3d-b564-b98671724600'
  name: origin
  url: https://sanford.example/repo.git
  public_url:
  archived: false
  disabled: false
  created_at: '2026-08-14T06:48:36.764426Z'
  updated_at: '2026-08-14T06:48:36.764426Z'
user:
  name: mary
  groups:
  - manager
  - purchasing
parent_order:
- project
- environment
- change
parents:
  project:
    id: bb7bef85-805f-43d9-a267-7e901630ffa0
    code: fin
    name: Finance
    description: Finance applications
    archived: false
    created_by: xiao
    project_type: Standard
  environment:
    id: 530d796b-60ff-4bc6-ad09-ac3eaf1afa45
    code: rcv
    name: Receivables
    description: RMS
    archived: false
    created_by: althea
api_key: eyJhbGciOiJIUzI1NiJ9.example.jwt

Footnotes

1. The attributes available within these context keys are the same as those available to you from the relevant API endpoint. See the OpsChain API documentation for more details. ↩ ↩² ↩³ ↩⁴ ↩⁵