fix: push trigger in generated publish workflow never ran any jobs

[EMaher]

The apiops init GitHub Actions publish workflow had a push trigger, but every publish-* job was gated on github.event.inputs.ENVIRONMENT, which is undefined on push events. The trigger fired but all jobs were skipped — a silent no-op.

Changes

• src/templates/github-actions/publish-workflow.ts

  • First environment's job condition now includes || github.event_name == 'push', so merges to main automatically trigger an incremental publish
  • On push, COMMIT_ID_CHOICE is undefined → != 'publish-all-artifacts-in-repo' is true → --commit-id ${{ needs.get-commit.outputs.commit_id }} is passed automatically
  • Subsequent environments remain gated on explicit workflow_dispatch (safe default for production)
  • Comments updated to show how to opt subsequent environments into sequential push-triggered deployment

• tests/unit/templates/github-actions/publish-workflow.test.ts

  • 3 new tests: first env condition includes push trigger, subsequent envs do not, incremental step correctly wires --commit-id for push case

Before (first env job, all envs identical):

if: github.event.inputs.ENVIRONMENT == 'dev'   # always false on push

After:

# Automatically deploys to dev on push to main (incremental mode) or when selected via workflow_dispatch
if: github.event.inputs.ENVIRONMENT == 'dev' || github.event_name == 'push'

[EMaher]

@copilot Have the Squad fan out and verify the code changes make the default behavoir for apiops init --ci azuredevops match the behavior description in https://azure.github.io/apiops/apiops/5-publishApimArtifacts/apiops-github-4-2-pipeline.html.

Create pipeline to automatically push changes using publisher tool
Go back to the PR that was created in the previous step as a result of running the extractor. Once the PR is merged the run-publisher pipeline should automatically trigger. Remember that the publisher pipeline requires manual approval before promoting between stages. To promote to the prod environment, wait on the dev stage to succeed and then click on the “Review deployments” button and approve to deploy the changes to the prod environment. approve promotion to prod environment

Specifically, I think the 'require human approval' part is missing.

[Copilot]

@copilot Have the Squad fan out and verify the code changes make the default behavoir for apiops init --ci azuredevops match the behavior description in https://azure.github.io/apiops/apiops/5-publi...

Done in commit d9170d6. Here's what changed:

GitHub Actions (publish-workflow.ts):

• All environments now chain sequentially on push to main (not just dev): each non-first job gets needs: [get-commit, publish-{previousEnvironment}]
• This makes all environments run in the same workflow run, which is required for the GitHub "Review deployments" approval button to appear
• Non-first environments now include a comment directing users to configure Required Reviewers under Settings > Environments > {env} — that's the mechanism that gates promotion with human approval

Azure DevOps (publish-pipeline.ts):

• Fixed a pre-existing YAML structure bug: dependsOn is now correctly placed inside the stage definition (previously it was placed before - stage:, outside the entry)
• Non-first stages include a comment directing users to configure approval checks in Pipelines > Environments > {env}
• The sequential dependsOn chaining was already in place; the approval gate is now explicitly documented

Both templates now match the documented behavior: push to main → auto-deploys to first env (incremental, using --commit-id) → subsequent envs require human approval before proceeding.

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:

• azure.github.io
  • Triggering command: /home/REDACTED/work/_temp/ghcca-node/node/bin/node /home/REDACTED/work/_temp/ghcca-node/node/bin/node --enable-source-maps /home/REDACTED/work/_temp/copilot-developer-action-main/dist/index.js (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)