Reusable Workflows u0026 Composite Actions Quiz Quiz

Evaluate your understanding of reusable workflows and composite actions with practical questions focusing on structure, invocation, and best practices. Assess your ability to implement automation efficiently and recognize key distinctions between these two powerful automation techniques.

  1. Identifying Correct Calls for Reusable Workflows

    Which option correctly shows how a workflow file can call a reusable workflow using the 'uses' keyword within a job?

    1. uses: ./.github/workflows/deploy.yaml
    2. use: actions/deploy@v1
    3. uses: deploy-workflow@main
    4. run: ./deploy-workflow

    Explanation: The correct syntax for invoking a reusable workflow is to use the 'uses' keyword followed by the repository and workflow file reference, such as 'deploy-workflow@main'. The first option refers to a local path, which is incorrect for reusable workflows. The third option contains a typo, using 'use' instead of 'uses'. The fourth option attempts to run a file directly rather than using the workflow's invocation mechanism.

  2. Inputs in Composite Actions vs. Workflows

    How can you define input parameters for a composite action so the value can be passed when it is called?

    1. Add inputs as variables in the YAML header only
    2. Use 'with' field inside steps only
    3. Declare inputs under the 'inputs' section at the root level of the action definition
    4. Define inputs under 'env' in each job

    Explanation: To accept input parameters in a composite action, they must be defined in the 'inputs' section at the root of the action definition file. Placing them under 'env' in jobs sets environment variables, not action inputs. Using 'with' inside steps is only for providing input values after they are defined, not for declaring them. Adding variables in the YAML header alone does not correctly define structured inputs.

  3. Composite Actions: Step Types and Capabilities

    Which of the following statements is true regarding the step types supported within composite actions?

    1. Composite actions can use 'call' to invoke workflows directly
    2. Composite actions can include both 'run' and 'uses' steps
    3. Composite actions only support 'run' steps
    4. Composite actions must use only shell scripts

    Explanation: Composite actions are versatile and may contain both 'run' steps (for shell commands) and 'uses' steps (to wrap other actions). Limiting to only 'run' steps is incorrect, as is stating they must be shell scripts. The 'call' keyword is not valid; workflows can't be invoked directly from composite actions in this manner.

  4. Workflow Outputs and Consumption

    In a scenario where a reusable workflow sets an output called 'deploy-url', how can the calling workflow access this output?

    1. Referencing 'steps.deploy-url' in the job
    2. Directly referencing 'outputs.deploy-url' as a global variable
    3. Using 'jobs.u003Cjob_idu003E.outputs.deploy-url' in the calling workflow
    4. Accessing 'environment.deploy-url' without extra configuration

    Explanation: The output from a reusable workflow is accessed in the calling workflow using the syntax 'jobs.u003Cjob_idu003E.outputs.deploy-url'. Referencing 'steps.deploy-url' is suited for step outputs, not workflow outputs. There is no global 'outputs.deploy-url' variable without further context. The environment variable approach does not provide access to workflow outputs directly.

  5. Purpose and Use Cases for Composite Actions

    What is a primary advantage of using a composite action for repeated logic, such as setting up environment variables and running tools, across multiple workflows?

    1. Composite actions execute faster than workflow jobs by default
    2. They enable code reuse by packaging multiple steps as a single action
    3. Composite actions are the only way to run shell scripts in workflows
    4. They automatically manage artifact storage without setup

    Explanation: Composite actions are designed to promote code reuse by grouping several steps into a single reusable action, making workflow files cleaner and more manageable. They are not the exclusive mechanism for running shell scripts, nor do they inherently make steps execute faster. Artifact management is not a built-in feature of composite actions without explicit configuration.