Post Build

A post-build pipeline definition may be associated with an individual project or with a workspace. The post-build definition file is created from a template profile contributed by the SDK when the project or workspace is generated. A unique ID is used to refer to the profile.

The template must have YAML format, and contain three top-level keys parameters, constants and steps. The final post-build description file is written to the root of the project or workspace directory.

Sections

parameters

The parameters section contains a list of parameter definitions to be used in the steps section. The name property is required, and indicates that the parameter is available for use in the pipeline. The associated value for the parameter is passed to the post-build tool at runtime when the pipeline is evaluated, e.g. as a command-line argument.

constants

The constants section contains a list describing two types of constants:

• a literal constant
• a path to another post-build definition file to import constants from

The constants are for use in the steps section of the post-build file.

Literal Constants

A literal constant has a name and an associated value, both of which are mandatory. It is not possible to override a constant from the command line, since constant expansion in some cases needs to happen separately from executing the post-build pipeline. One example of this is when evaluating the path to an output artifact.

Imported Constants

To import constants from another post-build definition file, only the path key pointing to the other file is required. The other file uses the export key to declare values to be exported from its steps section for use in the post-build file importing it. The literal constants from the other file are not exported.

When constants are imported from the steps section of another post-build definition file, the export key defines the name of the constant, and the output key defines the value of the constant. Since outputs contain paths relative to the post-build definition file, the imported value must be transformed to take the relative path difference between the two post-build definition files into account.

If the output makes use of local constants from the file in which it's defined, the string is expanded using available literal constants prior to exporting. Recursively importing constants from yet another post-build file is not supported. It is considered an error if an exported output value makes use of a parameter, since it doesn't have an assigned value at the time of exporting.

steps

The steps section contains a list of steps to execute in order. Each step must contain the following information:

Key	Type	Description
task	String	The type of task this step invokes
output	String	Path to the output artifact from the step
export (optional)	String	Export the output artifact path as a parameter with this name, for use in another post-build pipeline. Used to share artifacts from projects with the workspace.

The given task type must be selected from a set of tasks supported by the post-build tool implementation. In addition to the above keys, the post-build tool implementation may require specific additional keys depending on the task type. These are implementation defined, and not documented in detail as part of the SLC post-build specification.

Post Build for SLC Projects

When a SLC project refers to a post-build template profile, the profile is copied to the project as part of project generation if it does not already exist. The copied template is given the name <project_name>.slpb. The SLC project file is updated to point to the copied file when running new project generation.

The SLC project generator makes the following modifications to the template when adding it to the project:

• Addition of project_name constant if it doesn't already exist
• Addition of build_dir parameter if it doesn't already exist

On subsequent regeneration of the project, the existing pipeline file is modified:

• Replacement of the value for project_name parameter

The post-build pipeline is automatically executed at the end of the build with the following parameter values passed as command line arguments:

• build_dir - Build directory containing output artifacts

Example

parameters:
  - name: build_dir

constants:
  - name: project_name
    value: my_project

steps:
  # Copy binary artifact
  - task: copy
    input: "{{build_dir}}/{{project_name}}.s37"
    output: "artifact/{{project_name}}.s37"
    export: bootloader_binary

  # Combine first stage and main bootloader
  - task: convert
    input:
      - "autogen/first_stage.s37"
      - "artifact/{{project_name}}.s37"
    output: "artifact/{{project_name}}-combined.s37"
    export: bootloader_combined_binary

Post Build for SLC Workspaces

When a SLC workspace has an associated post-build template profile, the profile is copied to the workspace as part of generation if it does not already exist. The generator modifies the constants section to add path references to all project-level post-build files, to make exported constants from the projects available to the workspace pipeline.

On subsequent generation of an already-existing post-build definition file, known constants are updated with new values, while constants unknown to the SLC workspace generator are left as-is.

Example

parameters: []

constants:
  - name: workspace_name
    value: my_workspace
  - path: ../my_bl/my_bl.slpb
  - path: ../my_app/my_app.slpb

steps:
  # Create production image
  - task: convert
    input:
      - "{{bootloader_combined_binary}}"
      - "{{"application_binary}}"
    output: "artifact/{{workspace_name}}-full.s37"

  # Create upgrade image
  - task: create_gbl
    bootloader: "{{bootloader_binary}}"
    app: "{{application_binary}}"
    output: "{{workspace_name}}-upgrade.gbl"