Rename "depends" parameter to "needs" in custom jobs to match GitHub Actions terminology

[Copilot]

This PR renames the depends parameter to needs in custom job definitions within workflow frontmatter to align with GitHub Actions standard terminology.

Problem

The current implementation uses depends as the parameter name for job dependencies in custom jobs, which is inconsistent with GitHub Actions' standard needs clause:

# Before (non-standard)
jobs:
  deploy:
    runs-on: ubuntu-latest
    depends: [build, test]  # ❌ Custom parameter name

# After (GitHub Actions standard)
jobs:
  deploy:
    runs-on: ubuntu-latest
    needs: [build, test]    # ✅ Standard GitHub Actions parameter

Solution

This change updates the frontmatter parser and internal job representation to use needs instead of depends:

1. Frontmatter parsing: The compiler now looks for needs instead of depends when processing custom job definitions
2. Internal representation: The Job struct field is renamed from Depends to Needs
3. YAML generation: Dependencies are still correctly rendered as needs: clauses in the generated GitHub Actions workflows
4. Validation: All existing dependency validation logic continues to work unchanged

Examples

Single dependency:

jobs:
  test:
    runs-on: ubuntu-latest
    needs: build

Multiple dependencies:

jobs:
  deploy:
    runs-on: ubuntu-latest  
    needs: [build, test]

Breaking Change

⚠️ This is an intentional breaking change - workflows using the old depends parameter will need to update to use needs. The old parameter is no longer supported and will result in a schema validation error.

Testing

• ✅ All existing tests updated and passing
• ✅ Manual verification of single and multiple dependency scenarios
• ✅ Confirmed old depends parameter is properly rejected
• ✅ Generated YAML produces correct needs: clauses
• ✅ Dependency validation and cycle detection continue to work correctly

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• api.contoso.com
  • Triggering command: /tmp/go-build2030490951/b278/cli.test -test.testlogfile=/tmp/go-build2030490951/b278/testlog.txt -test.paniconexit0 -test.timeout=10m0s -test.v=true (dns block)
  • Triggering command: /tmp/go-build2232456022/b278/cli.test -test.testlogfile=/tmp/go-build2232456022/b278/testlog.txt -test.paniconexit0 -test.timeout=10m0s -test.v=true (dns block)
  • Triggering command: /tmp/go-build2110069848/b278/cli.test -test.testlogfile=/tmp/go-build2110069848/b278/testlog.txt -test.paniconexit0 -test.timeout=10m0s -test.v=true (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.