nicokosi / gh-collab-scanner

🔎 A GitHub CLI extension that displays collaboration-related information about a GitHub repository.

In my free time, I occasionaly blog here. ✍️

I also like collaborating on TLDR, Collaborative cheatsheets for console commands. 📖

My kanban for personal projects and learning experimentations. 👁‍🗨

personal "tool" projects 🛠️

• dotfiles: my professional/personal shell configurations 🐚
• blog: my blog's content ✍️
• java-for-katas: a basic Java setup for code katas 🥋
• gh-collab-scanner: a GitHub CLI extension that displays collaboration-related information about GitHub repositories. 🔍

personal "toy" projects 🧪

• hubstats, pullpito, pullpitoK and pullpigo: CLI tools to experiment with Clojure, Rust, Kotlin and Go programming languages. 🧑‍💻
• dom-manipulator: experimentations with JavaScript/TypeScript, HTML and CSS. 🧑‍🎨

gh-collab-scanner's Issues

Current repository not detected if `gh auth` is not configured for `ssh`: `unable to determine current repository, none of the git remotes configured for this repository point to a known GitHub host`

gh collab-scanner v1.0.3 (see fix d6f96de) issues this failure on my Ubuntu machine:

$ gh collab-scanner --verbose                                                                                                                                                            
(current repo)
unable to determine current repository, none of the git remotes configured for this repository point to a known GitHub host

$ pwd
/home/nkosinski/work/gocode/gh-collab-scanner

$ git config --local --list | grep "^remote."                                                                                                                                             
[email protected]:nicokosi/gh-collab-scanner.git
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*

$ lsb_release -d
Description:	Ubuntu 20.04.4 LTS

$ gh version
gh version 2.5.2 (2022-03-01)
https://github.com/cli/cli/releases/tag/v2.5.2

PS: it works OK on my other machine (macOS).

Fails `panic: runtime error: invalid memory address or nil pointer dereference` on Ubuntu :boom:

gh collab-scanner v1.0.1 fails when launched from a cloned repository, on my Ubuntu machine:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0x6c5680]

goroutine 1 [running]:
main.getRepo(0x0, 0x0, 0x7f7aaddad100, 0x168, 0x915ec0)
	/home/runner/work/gh-collab-scanner/gh-collab-scanner/main.go:62 +0x60
main.main()
	/home/runner/work/gh-collab-scanner/gh-collab-scanner/main.go:39 +0x65

lsb_release -d
Description:	Ubuntu 20.04.4 LTS

Output has a single line if multiple repositories (`--user` or `--org` flag)

gh-collab-scanner v1.2.0 outputs a single line per repository when using the --useror --org flag:

$ gh collab-scanner --org softwarevidal
softwarevidal/airflow-dags: README ☑️, topics ☑️, 30 collaborators 👥, softwarevidal/alexandrie: no README 😇, topics ☑️, 30 collaborators 👥, softwarevidal/amazon_iha: README ☑️, no topics 😇, 16 collaborators 👥, softwarevidal/ameli-medicam: README ☑️, no topics 😇, ^C

It should output a line per repository (a carriage returns should be added so that each line starts with the repository name).

Repository no detected from current folder `gh collab-scanner`

With v1.2.2:

$ pwd
/Users/nicolas/work/gh-collab-scanner
$ gh collab-scanner
$

Seems to be a regression from a1ffb2f. 😇

Filter repositories by `topic` for a given user or org

For instance, gh collab-scanner -org pytest-dev -topic testing would only scan these 10 repositories:

Scan all items from the community standard checklist?

For open source projects, it would be nice to give details about the community profile score.
The GitHub community standard checklist visibly has these details. In addition to a description and a README, it also has:

• Code of conduct
• Contributing
• Licence
• Issue Templates
• Pull Request Template

Use Go 1.18 🎉

Go 1.18 has been released on 2022/03/15 (see release history). Let's keep up-to-date! 🎉

PS: have a look at this paragraph:

go version

The go command now embeds version control information in binaries. It includes the currently checked-out revision, commit time, and a flag indicating whether edited or untracked files are present. Version control information is embedded if the go command is invoked in a directory within a Git, Mercurial, Fossil, or Bazaar repository, and the main package and its containing main module are in the same repository. This information may be omitted using the flag -buildvcs=false.

Fix the `community profile score` issue for forked repositories: `HTTP 404: Not Found` 🐛

For instance, with collab-scanner v1.0.5:

gh collab-scanner --repo nicokosi/gilded-rose-kata
README ☑️, no topics 😇, 1 collaborator 👤, HTTP 404: Not Found (https://api.github.com/repos/nicokosi/gilded-rose-kata/community/profile)

Scan all repositories from an organization

For instance, the following command:

gh collab-scanner --org python

could scan all organization's repositories (via the GitHub /orgs/{org}/repos API) and output:

python/.github: no README 😇, no topics 😇, community profile score: 28 💯
python/asyncio: README ☑️, topics ☑️, community profile score: 42 💯
# and so on...

Handle pagination via `--page` flags for organisation flag (`--org`) and user flag (`--user`)

Related resources:

• cli/go-gh#23
• https://docs.github.com/en/rest/overview/resources-in-the-rest-api#pagination

Missing repository names when using the `--org` flag

For instance, the command gh collab-scanner --org softwarevidal displays:

README ☑️, topics ☑️, 30 collaborators 👥
no README 😇, topics ☑️, 30 collaborators 👥
README ☑️, no topics 😇, 14 collaborators 👥
README ☑️, no topics 😇, 30 collaborators 👥
no README 😇, no topics 😇, 16 collaborators 

gh collab-scanner --version

Commit 08f779b43853bc8f422bedcbbdb205e433d4f47c (2022-04-04 04:51:12 +0000 UTC) (dirty)

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

This repository currently has no open or pending branches.

Detected dependencies

github-actions

.github/workflows/ci.yml

• actions/checkout v4
• actions/setup-go v5

.github/workflows/release.yml

• actions/checkout v4
• cli/gh-extension-precompile v1

gomod

go.mod

• go 1.21
• github.com/cli/go-gh/v2 v2.5.0
• github.com/stretchr/testify v1.8.4
• gopkg.in/h2non/gock.v1 v1.1.2

---

• Check this box to trigger a request for Renovate to run again on this repository

Scan all repositories from a user

For instance, the following command:

gh collab-scanner --user torvalds

could scan all organization's repositories (via the GitHub /users/{org}/repos API) and output:

torvalds/.github: README ☑️...
torvalds/linux: README ☑️...
# and so on...

Add support for secure token storage

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

Output the version via a `--version` flag

gh collab-scanner --version could output its semantic version (i.e. 1.2.2) or the last commit.