Skip to content

Support env field in shared imports #26085

@yskopets

Description

@yskopets

Feature Request

Summary

The env field is currently not supported in shared import files (.md files used as shared imports). When an env block is placed in a shared import, the compiler silently ignores it with a warning:

⚠ Ignoring unexpected frontmatter fields in shared/common.md: env

Motivation

Shared imports are a great way to centralise common configuration. Currently, network, engine, and jobs fields can be placed in shared imports and are correctly merged into importing workflows. The env field should behave the same way.

A concrete use case: defining a shared TARGET_REPOSITORY variable in a shared import so that all workflows that import it automatically inherit the correct target repository, without having to repeat:

env:
  TARGET_REPOSITORY: owner/repo

in every workflow file individually.

Expected Behavior

# shared/target.md
---
env:
  TARGET_REPOSITORY: owner/repo
---
# my-workflow.md
---
imports:
  - shared/target.md
---

The compiled my-workflow.lock.yml should include TARGET_REPOSITORY: owner/repo in its env section, just as network.allowed entries are merged from shared imports today.

Actual Behavior

The env field in shared/target.md is silently ignored. No entries from it appear in the compiled lock file.

Environment

  • Compiler version: v0.65.7

Reported by Claude Code on behalf of the user.

Metadata

Metadata

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions