Actions YAML Strict Schema Validation Error detected:\nFor m

Error message

Actions YAML Strict Schema Validation Error detected:\nFor more information, see: https://nektosact.com/usage/schema.html

What it means

WorkflowStrict.UnmarshalYAML behaves like the non-strict version but validates against the workflow-root-strict schema definition, which additionally rejects unknown/extra keys that normal GitHub parsing silently ignores. Strict mode is opt-in (e.g. the strict planner path) and surfaces latent workflow issues as hard errors.

Source

Thrown at pkg/model/workflow.go:99

		return errors.Join(err, fmt.Errorf("Actions YAML Schema Validation Error detected:\nFor more information, see: https://nektosact.com/usage/schema.html"))
	}
	type WorkflowDefault Workflow
	return node.Decode((*WorkflowDefault)(w))
}

type WorkflowStrict Workflow

func (w *WorkflowStrict) UnmarshalYAML(node *yaml.Node) error {
	// Resolve yaml anchor aliases first
	if err := resolveAliases(node); err != nil {
		return err
	}
	// Validate the schema before deserializing it into our model
	if err := (&schema.Node{
		Definition: "workflow-root-strict",
		Schema:     schema.GetWorkflowSchema(),
	}).UnmarshalYAML(node); err != nil {
		return errors.Join(err, fmt.Errorf("Actions YAML Strict Schema Validation Error detected:\nFor more information, see: https://nektosact.com/usage/schema.html"))
	}
	type WorkflowDefault Workflow
	return node.Decode((*WorkflowDefault)(w))
}

type WorkflowDispatchInput struct {
	Description string   `yaml:"description"`
	Required    bool     `yaml:"required"`
	Default     string   `yaml:"default"`
	Type        string   `yaml:"type"`
	Options     []string `yaml:"options"`
}

type WorkflowDispatch struct {
	Inputs map[string]WorkflowDispatchInput `yaml:"inputs"`
}

func (w *Workflow) WorkflowDispatchConfig() *WorkflowDispatch {

View on GitHub (pinned to 4f41128141)

Solutions

Remove the unknown/extra keys named in the joined schema errors.
Migrate deprecated syntax flagged by strict validation to the modern equivalent.
If the extra keys are harmless, re-run without strict mode until the workflow is cleaned up.

Example fix

# before (strict rejects unknown key)
jobs:
  build:
    runs-on: ubuntu-latest
    continiue-on-error: false
# after
jobs:
  build:
    runs-on: ubuntu-latest
    continue-on-error: false

Defensive patterns

Strategy: validation

Validate before calling

// smoke-test strict parsing before enabling strict mode broadly
_, err := model.ReadWorkflowStrict(bytes.NewReader(raw))
if err != nil { return fmt.Errorf("strict validation failed: %w", err) }

Try / catch

if err != nil && strings.Contains(err.Error(), "Strict Schema Validation Error") {
    // unwrap joined errors; remove or correct each flagged key, then re-run
}

Prevention

Adopt strict mode gradually: run it in CI as advisory before making it blocking.
Delete dead/deprecated keys during periodic workflow cleanup.
Prefer actlint/actionlint plus strict act parse in pre-commit hooks.

When it happens

Trigger: Enabling strict reading (ReadWorkflow with strict=true / WorkflowStrict) on a workflow containing deprecated or non-schema keys, such as old `::` syntax remnants, unknown job-level keys, or environment shortcuts the strict schema disallows.

Common situations: Running act in strict mode on legacy workflows; CI linting that turns on strictness; workflows that run fine on GitHub but carry extra keys.

Related errors

AI-assisted analysis of nektos/act@4f41128141 (2026-08-15). Data as JSON: /api/errors/1e7314ef98c01c8a. Report an issue: GitHub.