Could copilot-setup-steps job also support needs parameter, or some other form of reusable gitops variable sharing?

[lkraav]

Select Topic Area

Question

Copilot Feature Area

Copilot Coding Agent

Body

Docs are pretty blunt about this

https://docs.github.com/en/copilot/how-tos/use-copilot-agents/coding-agent/customize-the-agent-environment#preinstalling-tools-or-dependencies-in-copilots-environment

In your copilot-setup-steps.yml file, you can only customize the following settings of the copilot-setup-steps job. If you try to customize other settings, your changes will be ignored.
steps (see above)
permissions (see above)
runs-on (see below)
container
services
snapshot
timeout-minutes (maximum value: 59)

I'm trying to hook in a reusable workflow to restore a small-planet-sized node_modules set in a monorepo like

...

jobs:
  try-cache-node-modules:
    uses: ./.github/workflows/cache-node-modules.yml
    concurrency:
      group: Cache node_modules-${{ github.event.pull_request.number || github.ref }}
      cancel-in-progress: true

  # The job MUST be called `copilot-setup-steps` or it will not be picked up by Copilot.
  copilot-setup-steps:
    runs-on: ubuntu-latest
    needs: try-cache-node-modules

...

      - uses: actions/cache/restore@v4
        id: try-cache-restore
        with:
          key: node_modules-${{ hashFiles('**/package-lock.json') }}
          path: ${{ needs.try-cache-node-modules.outputs.NODE_MODULES_PATHS }}
          fail-on-cache-miss: 'true'

...

But jobs.try-cache-restore.path variable is empty because needs, otherwise a standard variable sharing mechanic between jobs, cannot be accessed? What are my Git-based options? I'd like to avoid adding this to GH Variables.

[abir2afridi]

Yes, you can make a reusable setup job like copilot-setup-steps support needs or share variables GitOps-style, but there are a few nuances depending on how you’re defining it (reusable workflow, composite action, or within a single workflow).

[tanushbhootra576]

copilot-setup-steps unfortunately cannot use needs or consume outputs from other jobs. Copilot ignores anything outside the small set of allowed fields, so the usual job-to-job variable sharing (needs.<job>.outputs.*) won’t work.

Right now the only Git-based options that do work are:

1. Put the cache logic directly inside copilot-setup-steps, even if it duplicates some steps.
2. Move the shared logic into a composite action, and call that action from inside copilot-setup-steps. This is the closest thing to GitOps-style reuse that Copilot supports today.
3. Use files in the repository (for example writing a list of paths to a file) instead of cross-job outputs.

What is not supported:

• needs inside copilot-setup-steps
• Reusable workflow outputs
• Cross-job outputs of any kind

Until GitHub expands the allowed fields, composite actions are the only reliable way to reuse logic without using environment/organization variables.

[tanushbhootra576]

copilot-setup-steps does not support needs, job outputs, or any cross-job variable sharing. Copilot only honors a very small set of fields for this job, and anything outside that list is ignored — including needs.<job>.outputs.*.

Because of this, standard GitHub Actions patterns like:

• chaining jobs with needs
• using reusable workflow outputs
• passing data between jobs

do not work for copilot-setup-steps.

What does work today:

1. Move the cache logic directly into copilot-setup-steps (even if it duplicates steps).
2. Convert your reusable logic into a composite action, then call that action inside copilot-setup-steps. This is the closest reliable GitOps-style reuse currently supported.
3. Use repository files (write/read a file with paths or metadata) instead of job outputs.

What is not supported:

• needs: inside copilot-setup-steps
• Cross-job outputs
• Reusable workflow outputs
• Any job wiring outside the allowed fields

Until GitHub expands the supported fields, composite actions are the only safe way to reuse logic without storing anything in org/environment variables.

[lkraav]

Yes, composite action was mostly what I was looking for here.

Something like .github/actions/get-node-modules-paths/action.yml seems to work well (enough):

name: get-node-modules-paths
description: Shared variable
outputs:
  NODE_MODULES_PATHS:
    description: 'Multi-line string of `node_modules` paths to calculate cache hashes'
    value: ${{ steps.set.outputs.NODE_MODULES_PATHS }}
runs:
  using: 'composite'
  steps:
    - id: set
      # @see https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-commands#multiline-strings
      run: |
        cat >> $GITHUB_OUTPUT <<'EOF'
        NODE_MODULES_PATHS<<DELIMITER
        node_modules
        apps/*/node_modules
        packages/lib/node_modules
        DELIMITER
        EOF
      shell: bash

Although having now grokked reusable vs composite, in tune with a few other suggestions here, I refactor the whole cache restore step set into a single composite action.

[tanushbhootra576]

copilot-setup-steps unfortunately cannot consume needs: or any job outputs because Copilot only honors a very small, fixed subset of job fields. Anything outside that list — including needs, job outputs, or reusable workflow outputs — is ignored during the agent environment setup phase.

Because of that limitation, cross-job variable sharing simply isn’t possible for copilot-setup-steps.

What does work today:

1. Use a composite action
   This is the only reliable, Git-based way to reuse logic without relying on org/environment variables. Moving your cache-restore logic (or the path-derivation logic) into a composite action is the cleanest workaround.

2. Keep all logic within copilot-setup-steps
   Slightly less DRY, but fully supported.

3. Use repository files as an exchange mechanism
   (e.g., write a file containing paths, read it later inside the same job), but this still can’t cross job boundaries.

Not supported:

• needs: inside copilot-setup-steps
• cross-job outputs
• reusable workflow outputs
• any job-to-job wiring outside the allowed fields

Until GitHub expands support for the setup job, composite actions are the only practical and future-proof way to share variables or logic in Copilot’s setup environment.