Follow up of https://github.com/cli/cli/pull/7612
The `missingWorkflowScopeRE` is defined to capture
the error message when the `GH_TOKEN` does not have
`workflow` scope in `gh repo sync <remote>`,
but this is only intended for error messages for
OAuth Apps and does not work with GitHub Apps.
In GitHub App, you will get the following error:
```
{
"message": "refusing to allow a GitHub App to create or update workflow `.github/workflows/teamcity-pr-checks.yml` without `workflows` permission",
"documentation_url": "https://docs.github.com/rest/branches/branches#sync-a-fork-branch-with-the-upstream-repository",
"status": "422"
}
```
As you can see above, the existing regexp does not
match the "`workflows` permission".
This change modifies the regexp to return
the user-friendly error message when the `workflow`
permission is missing, even in the case of a GitHub App.
Previously, we were getting the token from repository secrets. We have
moved the token to its own environment secret in the
cli-discuss-automation environment. It is in its own environment so that
we don't inject our other secrets into this workflow as we don't need
them here.
The previous commit failed to update the 2nd set of tests to rely upon GH_REPO instead of --repo flag.
These have been tested against `trunk` and fail because not being in a git directory when they should pass.
This commit builds on top of work previously done within acceptance tests around gh secret and remote disambiguation.
The choice of expanding this existing test rather than creating a new test was in order to keep context together within a single acceptance test rather than splitting it over multiple.
Building on top of the work done in commands to account for GH_REPO environment variable, this commit expands existing tests around handling base repo functions to include new test scenarios.
These tests fail in the same way as reported on the issue when run against `trunk` without the other branch's changes, demonstrating they will help avoid regression.
* Separate partitioning from globbing in cmdutil/args package and consumers
In the previous commit, GlobPaths was overloaded, containing logic
specific to command use-cases. This commit removes that functionality from
GlobPaths and back into the commands that have the special use-cases.
To do this, I've introduced a new Partition util in cmdutil/args.go that
will separate a slice into two slices given a predicate. This functionality
is leveraged by both the special use-cases described above to separate the
command-specific syntax from the globable filepaths.
* Add test to validate that the order of '-' in gh gist create args doesn't matter
FindWorkflow had a code path that could error without handling that error
that was introduced in #10328. I previously called out the lack of tests
in this part of the code in my review, and punting them then bit us here:
https://github.com/cli/cli/pull/10328#pullrequestreview-2597266783.
As such, this fixes the panic, but also adds tests to cover the relevant
code paths through FindWorkflow, including some tests for getWorkflowByID,
getWorkflowsByName, and GetWorkflows.
This does NOT seek to refactor the existing code, just cover the existing
behavior and validate that we are resolving this panic (covered by
TestFindWorkflow_nonHTTPError).
