Token storage change in latest release of gh

This is a message from the GitHub CLI team, maintainers of gh, writing to inform you that the most recent release of gh contains changes which may affect your extension. The latest release introduces the feature of storing authentication tokens in the system keyring (encrypted storage) instead of in a plain text file.
The keyrings that are supported are:

• Keychain on macOS

• GNOME Keyring on Linux (Secret Service dbus interface)

• Wincred on Windows

This has huge security benefits for the users of our tool and was one of our oldest outstanding issues. Unfortunately this change has the potential to break extensions that rely on utilizing the users authentication token to work.

In order to have continued compatibility with gh there are some actions you, as an extension author, need to take. These actions will depend on the implementation of your extension.

Extensions built in Go using go-gh:

1. Upgrade your go-gh version to v1.2.1, the latest version.

   • This can be done using go get github.com/cli/[email protected]

2. Verify that in your extension retrieval of the user authentication token is done using the auth.TokenForHost function.

   • If you were previously accessing the authentication token using any other method it will no longer work.
   • Automatic resolution of the authentication token when using the API clients will continue to work without changes.

All other extensions:

1. Verify that in your extension retrieval of the user authentication token is done by shelling out to the gh auth token command.

   • If you were previously accessing the authentication token using the gh config get command, reading the configuration file directly, or any other methods it will no longer work.

As of right now storing the authentication token in the system keyring is an opt-in feature, but in the near future it will be required and at that point if the changes above are not made then your extension will be broken for all users. If you have any questions/concerns about this change please feel free to open a discussion in the gh repo.

Thanks,
The GitHub CLI Team

Support a Go-template PR template that is used by gh prx separate from the github repositories default location. This would allow users of gh prx CLI to create templated pull-requests but also allow users to create pull-requests from the Web UI using a non-templated markdown template.

.github/PULL_REQUEST_TEMPLATE.md

E.g. ideally a user could specify in their .github/.gh-prx.yaml

pr:
   title: "{{.Type}}{{.Prefix}}{{with .Issue}}({{.}}){{end}}: {{humanize .Description}}" # PR title template
   ignore_commits_patterns: ["^wip"] # Patterns to filter out a commits from the {{.Commits}} variable
   answer_checklist: false # Whether to prompt the user to answer PR description checklists. Possible answers: yes, no, skip (remove the item)
   push_to_remote: true # Whether to push the local changes to remote before creating the PR
issue:
   provider: jira # The provider to use for fetching issue details (supported: github,jira,linear)
   types: ["fix", "feat", "chore", "docs", "refactor", "test", "style", "build", "ci", "perf", "revert"] # The issue types to prompt the user when creating a new branch
   pull_request_template: .github/PULL_REQUEST_TEMPLATE.ghprx.md # default is .github/PULL_REQUEST_TEMPLATE.md
   ignore_pull_request_template: false # If true, the pull request template in the repository will be ignored.

Allow generating PR titles from management tool ticket in addition for parsing branch name.
It could be a parameter like for creating branch e.g. gh prx TCKT-1234 --web or additional flag gh prx TCKT-1234 --issue TCKT-1234 --web
When param or flag is used PR title is getting from management tool and title is composed according to template set in config file

Description

Allow running gh prx checkout-new without the issue argument, and fetch a list of user issues to choose from.

Thanks @yanilov for suggesting this!

Add support for checking out branches based on Linear.app issues.