Overview

In #7, @tspascoal made some initial changes to gh-repo-export for this to
work on Windows using Git Bash. This is based on discovery from
cli/cli#6415 where the leading slash of the API path
causes Windows to interpret it as a local file path.

This issue is to ensure these changes are implemented, tested, and released.

Action Items

Overview

There has been feedback from colleagues and users that a couple of additions to gh-repo-export would be welcomed:

1. Being able to read the list of repositories from a file rather than arguments
2. Being able to generate individual archive files rather than a bulk archive

This issue is for expanding gh-repo-export to support both of these enhancements along with updated documentation.

Action Items

Overview

Thanks to @katiem0 who made a solid call out that we don't document what permissions are necessary to export repositories!

This issue is to update documentation to reflect the permissions for v1 classic PATs that are required.

Overview

Thanks to feedback @esleyshaffer, it might be useful to expand on gh-repo-export tool to include documentation if not functionality around unlocking previously locked repositories in the case of rollback.

Using the "Unlock an organization repository
" endpoint, someone might want to delete the locks placed during a gh repo-stats --lock-repositories run. This should be easy enough to add except for reworking the option handling nature of the script.

Action Items

Overview

There are no GitHub Actions workflows for gh-repo-export, which doesn't help pull requests from contributors.

While I figure out how to safely provide workflows that cannot be subverted, I want to have some basic essential checks including shellcheck and maybe actionlint.

Action Items

The latest update to support a repos.txt file broke on my machine :(

$ gh repo-export joshjohanning-org repos.txt
Reading repositories from file: repos.txt
/Users/joshjohanning/.local/share/gh/extensions/gh-repo-export/gh-repo-export: line 142: declare: -A: invalid option
declare: usage: declare [-afFirtx] [-p] [name[=value] ...]

Looks like this might not work out of the box for macOS without updating bash?

My bash version:

$ bash --version
GNU bash, version 3.2.57(1)-release (arm64-apple-darwin22)
Copyright (C) 2007 Free Software Foundation, Inc.

https://stackoverflow.com/questions/6047648/associative-arrays-error-declare-a-invalid-option
https://www.ianoutterside.com/bash-invalid-option/

I can probably update my bash, but I'm assuming others may run into this as well. Unsure if there is a different way to solve this without using the declare -A command?

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