Hooks Registry

The hooks registry is a central location for storing and managing scripts for the workspace's custom hooks feature. Whether you need to install binaries, call external APIs, or do something else, hooks give you the flexibility your pipeline needs. Hooks in the registry are always stored in your VCS provider and pulled into Scalr to ensure you can use standard development practices.

Custom hooks can be added directly in the workspace, but in many cases, a common hook is needed across all workspaces in an environment or across the entire account. This is where the hooks registry helps. After adding a hook to the registry, it can be applied to an environment, which then applies it to all workspaces in the environment.

Hooks inherited by a workspace from the registry will execute before hooks created in the workspace. A hook created in the registry does not prevent a workspace level hook from being created in the same phase within the pipeline. For example, a workspace can have a pre-plan hook from the registry and a pre-plan hook created in the workspace. The registry hook will execute first, followed by the workspace-level hook.

Configuring a Hook

To configure a hook, navigate to the Scalr account scope, registries, and then click on hooks:

First, define the provider, repository, and branch from which the script must be pulled. Next, define the interpreter to ensure Scalr is calling the script correctly. Lastly, enter the path to the script. If the script is at the directory's root, enter the script name.

Using The Hook

Once the hook is created, it can be added to an environment, automatically applying it to all workspaces. Navigate to the environments page, select the environment, click on hooks, and enable hook:

Select the phases in which the hook should run, this will be applied to ALL workspaces in the environment.

Once saved, you will see the hook execute in the runs for all workspaces in that environment.

Using an Interpreter

Hooks in Scalr can be executed using a specific interpreter. By default, Scalr assumes the script is written in Bash (#!/bin/bash). However, you can specify a different interpreter by defining it in the appropriate field when registering the hook. This allows execution with interpreters such as Python (python3), or other supported shells.

Difference Between . and bash Execution

When executing hooks, there is a key difference between using . (source) and bash:

• Using . (source command): The script is executed in the current shell session, meaning any environment variable changes persist after execution.
• Using bash (or another shell directly): The script runs in a separate subshell, so any modifications to environment variables do not persist outside the script's execution context.

Exporting Environment Variables

During hook execution, if you need environment variables to persist, explicitly export them within the script:

export MY_VAR="some_value"

If using . to source a script, variables set without export will still be available in the current session, whereas in a subshell, they will not affect the parent shell.

Referencing Extra Files

In some cases, you may have a single repository with multiple scripts or files needed as part of the hook and Scalr will need to know how to call the extra files. In this case, the $SCALR_HOOK_DIR variable can be used to call other files or scripts that are needed in the hook. For example, the following script is defined in the hook, but this script relies on scripts.py, which is in the same repository and directory. By adding $SCALR_HOOK_DIR/scripts.py, Scalr will know where to find the additional files once they are pulled into the run time environment:

#!/usr/bin/env bash

set -e

pip3 install requests click --quiet

export YOR_SIMPLE_TAGS="$(python3 $SCALR_HOOK_DIR/scripts.py get-tags -h $SCALR_HOSTNAME -t $SCALR_TOKEN -r $SCALR_RUN_ID -d ':')"
echo $YOR_SIMPLE_TAGS
wget https://github.com/bridgecrewio/yor/releases/download/0.1.150/yor_0.1.150_linux_amd64.tar.gz -q
tar -xvf yor_0.1.150_linux_amd64.tar.gz
./yor tag --tag-groups simple -d ./ --skip-tags git*