Fix smoke-copilot workflow container tag mismatch#1144
Merged
Conversation
Co-authored-by: lpcox <15877973+lpcox@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes a container tag mismatch in the smoke-copilot workflow and upgrades the agentic workflow compiler from v0.46.1 to v0.47.1. The primary issue was that the MCP Gateway container build used the :latest tag while the compiler generated :v0.1.4 references in the lock file, which would cause the download step to pull the wrong image. The fix ensures consistent use of :latest throughout the workflow by properly configuring the container reference pattern and updating the lock file.
Changes:
- Fixed MCP Gateway container tag mismatch by ensuring all references use
ghcr.io/github/gh-aw-mcpg:latestconsistently in build, download, and runtime steps - Upgraded agentic workflow compiler from v0.46.1 to v0.47.1, which includes AWF version upgrade (v0.20.0 → v0.20.2) and several workflow improvements
- Added new features from compiler upgrade: GH_AW_GROUP_REPORTS environment variable, safe-output-items artifact upload, cache-memory content validation checks, and step name improvements
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This was referenced Feb 19, 2026
Merged
lpcox
added a commit
that referenced
this pull request
Feb 20, 2026
<!-- START COPILOT ORIGINAL PROMPT --> <details> <summary>Original prompt</summary> ---- *This section details on the original issue you should resolve* <issue_title>[compliance] Compliance Gap: `registry` field rejected despite being valid per spec</issue_title> <issue_description>## MCP Gateway Compliance Review — 2026-02-20 ## Summary Found **2 compliance issues** during daily review. One important issue (spec-valid field causes validation failure) and one minor gap (missing SHOULD feature). ## Recent Changes Reviewed - Commit `4cd522d` — Fix smoke-copilot workflow container tag mismatch (#1144) - Single grafted commit available in this environment; full history not accessible --- ## Important Issues (spec-valid field rejected) ### 1. `registry` Field Defined in Spec but Rejected by Schema Validation **Specification Section:** 4.1.2 Server Configuration Fields **Deep Link:** https://github.com/github/gh-aw/blob/main/docs/src/content/docs/reference/mcp-gateway.md#412-server-configuration-fields **Requirement:** > | `registry` | string | No | URI to the installation location when MCP is installed from a registry. This is an informational field used for documentation and tooling discovery. Applies to both stdio and HTTP servers. Example: `"https://api.mcp.github.com/v0/servers/microsoft/markitdown"` | **Current State:** The `registry` field is: - Not present in `StdinServerConfig` struct (`internal/config/config_stdin.go`) - Not present in `ServerConfig` struct (`internal/config/config_core.go:88–112`) - Not present in the pinned JSON schema at `v0.41.1` for either `stdioServerConfig` or `httpServerConfig` - Not present in the latest JSON schema on `main` for either type either Both `stdioServerConfig` and `httpServerConfig` in the JSON schema use `"additionalProperties": false`, so any configuration that includes `registry` will fail schema validation with an "additional property" error. **Gap:** The spec explicitly defines `registry` as a valid optional field for both stdio and http servers. Appendix A.5 includes complete examples of its use. However, the current implementation will **reject** any configuration containing this field. **Severity:** Important (spec defines a valid optional field that the implementation actively rejects) **File References:** - `internal/config/config_stdin.go` — `StdinServerConfig` struct (missing `Registry` field) - `internal/config/config_core.go:88–112` — `ServerConfig` struct (missing `Registry` field) - `internal/config/validation_schema.go:38` — pinned schema URL at `v0.41.1` - JSON schema at `v0.41.1`: `stdioServerConfig.additionalProperties = false`, no `registry` property - JSON schema at `main`: same — `registry` not present **Suggested Fix:** 1. Add `Registry` field to `StdinServerConfig`: ```go // Registry is the URI to the installation location in an MCP registry (informational) Registry string `json:"registry,omitempty"` ``` 2. Add `Registry` field to `ServerConfig`: ```go // Registry is the URI to the installation location in an MCP registry (informational) Registry string `toml:"registry" json:"registry,omitempty"` ``` 3. Add `registry` property to the JSON schema (or open a PR in `gh-aw` to update the pinned schema), and update the schema pin version once merged. 4. Pass `registry` through in `convertStdinConfig` if it needs to be preserved in the internal config. **Estimated Effort:** Small (1–2 hours) --- ## Minor Suggestions (SHOULD improvements) ### 2. No Random API Key Generation When `apiKey` Is Not Configured **Specification Section:** 7.3 Optimal Temporary API Key **Deep Link:** https://github.com/github/gh-aw/blob/main/docs/src/content/docs/reference/mcp-gateway.md#73-optimal-temporary-api-key **Requirement:** > The gateway SHOULD support temporary API keys: > 1. Generate a random API key on startup if not provided > 2. Include key in stdout configuration output **Current State:** In `internal/cmd/root.go:380`, `apiKey` is set to `""` when `cfg.Gateway.APIKey` is empty. No random key is generated, and the stdout output configuration omits `headers` entirely when there is no API key (`internal/cmd/root.go:406`). **Gap:** Clients connecting to a gateway with no configured API key must know to send no Authorization header. If a random key were auto-generated, the gateway would always have an auth layer and clients would get the key from the stdout configuration output. **Severity:** Minor (SHOULD, not MUST) **File References:** - `internal/cmd/root.go:380,406` - `internal/server/transport.go:62` **Estimated Effort:** Small (1–2 hours) --- ## Compliance Status | Section | Requirement | Status | |---------|-------------|--------| | 3.2.1 Containerization Requirement | stdio MUST be containerized | ✅ Compliant | | 4.1.2 Server Configuration Fields — `registry` | Valid optional field | ❌ Field rejected by schema | | 4.2 Variable Expression Rendering | Fail immediately on undefined variable | ✅ Compliant | | 4.3 Configuration Validation | Unknown fields rejected, sche... </details> <!-- START COPILOT CODING AGENT SUFFIX --> - Fixes #1162
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The smoke-copilot workflow was failing because the MCP Gateway container build used
:latesttag while the compiler generated:v0.1.4references in the lock file, causing the download step to pull the wrong image or fail.Changes
ghcr.io/github/gh-aw-mcpg:latest(unchanged)ghcr.io/github/gh-aw-mcpgregistry path pattern:v0.1.4→:latestafter compilationThis matches the pattern established in
language-support-tester.mdand ensures the locally-built container is used consistently throughout the workflow execution.The compiler's automatic
:v0.1.4tag append requires manual lock file adjustment when building locally with:latest.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:
https://api.github.com/repos/docker/setup-buildx-action/git/ref/tags/v3/usr/bin/gh gh api /repos/docker/setup-buildx-action/git/ref/tags/v3 --jq .object.sha --abbrev-ref HEAD /usr/bin/find(http block)/usr/bin/gh gh api /repos/docker/setup-buildx-action/git/ref/tags/v3 --jq .object.sha --abbrev-ref HEAD k/_temp/ghcca-node/node/bin/git get --local /usr/bin/git base64 -d(http block)/usr/bin/gh gh api /repos/docker/setup-buildx-action/git/ref/tags/v3 --jq .object.sha --abbrev-ref HEAD git REDACTED k/gh-aw-mcpg/gh-rev-parse(http block)https://api.github.com/repos/github/gh-aw-mcpg/actions/artifacts/5581948090/zip/usr/bin/gh gh api repos/github/gh-aw-mcpg/actions/artifacts/5581948090/zip git conf�� get --local /home/REDACTED/.local/bin/git credential.helpebase64(http block)https://api.github.com/repos/github/gh-aw-mcpg/actions/jobs/64224788574/usr/bin/gh gh run view 22204311434 --repo github/gh-aw-mcpg --log --job 64224788574(http block)https://api.github.com/repos/github/gh-aw-mcpg/actions/runs/22204311434/usr/bin/gh gh api repos/{owner}/{repo}/actions/runs/22204311434 --jq {databaseId: .id, number: .run_number, url: .html_url, status: .status, conclusion: .conclusion, workflowName: .name, workflowPath: .path, createdAt: .created_at, startedAt: .run_started_at, updatedAt: .updated_at, event: .event, headBranch: .head_branch, --global user.name ache/Python/3.12.12/x64/bin/node(http block)https://api.github.com/repos/github/gh-aw-mcpg/actions/runs/22204311434/artifacts/usr/bin/gh gh run download 22204311434 --repo github/gh-aw-mcpg --name agent-output /home/REDACTED/.nvm/nvm.sh /home/REDACTED/.nvm/package.json /home/REDACTED/.nvm/rename_test.sh /home/REDACTED/.nvm/test -P >�� user.email(http block)https://api.github.com/repos/github/gh-aw/git/ref/tags/v0.47.1/usr/bin/gh gh api /repos/github/gh-aw/git/ref/tags/v0.47.1 --jq .object.sha --abbrev-ref HEAD bin/git(http block)/usr/bin/gh gh api /repos/github/gh-aw/git/ref/tags/v0.47.1 --jq .object.sha --abbrev-ref HEAD cal/bin/git /g --local /opt/hostedtoolc--abbrev-ref base64 -d(http block)/usr/bin/gh gh api /repos/github/gh-aw/git/ref/tags/v0.47.1 --jq .object.sha --abbrev-ref HEAD /usr/bin/base64 --abbrev-ref HEAD(http block)If you need me to access, download, or install something from one of these locations, you can either: