Repository navigation
Conversation
|
@BagToad : Thanks for opening up this draft! ✨ How I I typically test these types of changes
Results of manual testingNote We need to follow up with the Here is the textual version: > Exit
A new release of gh-copilot is available: 1.0.6 → 1.1.0
https://github.com/github/gh-copilot/releases/tag/v1.1.0
A new release of copilot is available: 1.0.6 → 1.1.0
To upgrade, run: gh extension upgrade copilot
https://github.com/github/gh-copilot
A new release of gh is available: 2.67.20250306 → 2.68.1
https://github.com/cli/cli/releases/tag/v2.68.1Here is the visual version (with long text from extension cut off) |
27f9a37 to
cce46b9
Compare
There was a problem hiding this comment.
This breaks the acceptance tests which require func() ~int as the Main entry point.
➜ GH_ACCEPTANCE_HOST=github.com GH_ACCEPTANCE_ORG=gh-acceptance-testing go test -count=1 -tags=acceptance -run ^TestIssues$ ./acceptance -v
# github.com/cli/cli/v2/acceptance_test [github.com/cli/cli/v2/acceptance.test]
acceptance/acceptance_test.go:21:13: not enough arguments in call to ghcmd.Main
have ()
want (string)
It would be ok to introduce a new func AcceptanceMain in the acceptance test package which calls this ghcmd.Main(false). That said, I think it's a bit strange to special case this behaviour into main but I can't specifically think of a reason not to do it, so I say we just move forward with this and see where we get to.
|
Actually what do you think about this? //go:build !homebrew
package updater
var Enabled = false//go:build homebrew
package updater
var Enabled = trueThen update the homebrew build to This would uncouple them from the specific path. We could generalise this to |
|
@williammartin I think that's compelling. I'll close this PR for now, and bring the discussion back to the issue, since I'll likely open a fresh PR for that implementation. |

Fixes #10242