From skimming the open issues/commits/etc, my guess is probably not; but since it came up near the top of the google results when I was searching, I wanted to include a little snippet of how to achieve some similar features as this project by directly using the GitHub CLI:
We can use gh issue list to show the issues, and then by combining it with the --json and --template flags, we can choose which fields we want to include, and then format them for output:
⇒ gh issue list -h
List issues in a GitHub repository.
The search query syntax is documented here:
<https://docs.github.com/en/search-github/searching-on-github/searching-issues-and-pull-requests>
For more information about output formatting flags, see `gh help formatting`.
USAGE
gh issue list [flags]
FLAGS
--app string Filter by GitHub App author
-a, --assignee string Filter by assignee
-A, --author string Filter by author
-q, --jq expression Filter JSON output using a jq expression
--json fields Output JSON with the specified fields
-l, --label strings Filter by label
-L, --limit int Maximum number of issues to fetch (default 30)
--mention string Filter by mention
-m, --milestone string Filter by milestone number or title
-S, --search query Search issues with query
-s, --state string Filter by state: {open|closed|all} (default "open")
-t, --template string Format JSON output using a Go template; see "gh help formatting"
-w, --web List issues in the web browser
INHERITED FLAGS
--help Show help for command
-R, --repo [HOST/]OWNER/REPO Select another repository using the [HOST/]OWNER/REPO format
The only downside I'm currently aware of with this method is that it doesn't let me split the issues into separate output files (unless I ran it manually for each issue); though a little extra code/effort would probably resolve that aspect as well.
We can see the handlebars templates used by offline-issues here:
To keep things simple, I'll just create a similar go template that the CLI can utilise for the markdown. This would process each issue that's returned from the CLI query, and format it as markdown:
{{- range . -}}
# [Issue #{{ .number }}: {{ .title }}]({{ .url }})
{{ .body }}
## Comments:
{{- range .comments }}
### Comment by {{ .author.login }} ({{ .createdAt }})
{{ .body }}
[View comment on GitHub]({{ .url }})
{{ end }}
---
{{- end }}
This could then be used in a way similar to the following:
gh issue list --repo MYORG/MYREPO --limit 1 --json number,title,url,body,comments --template 'THE TEMPLATE FROM ABOVE'
Obviously this could be refined a bunch from here, but wanted to drop a quick 'half baked solution' here in case it's helpful to anyone either now, or in the future.
Edit: I've also capture the above on the following gist for future reference, and I might edit it to include a more refined version of this process at some point, so worth checking there as well in case:
From skimming the open issues/commits/etc, my guess is probably not; but since it came up near the top of the google results when I was searching, I wanted to include a little snippet of how to achieve some similar features as this project by directly using the GitHub CLI:
We can use
gh issue listto show the issues, and then by combining it with the--jsonand--templateflags, we can choose which fields we want to include, and then format them for output:The only downside I'm currently aware of with this method is that it doesn't let me split the issues into separate output files (unless I ran it manually for each issue); though a little extra code/effort would probably resolve that aspect as well.
We can see the handlebars templates used by
offline-issueshere:To keep things simple, I'll just create a similar go template that the CLI can utilise for the markdown. This would process each issue that's returned from the CLI query, and format it as markdown:
This could then be used in a way similar to the following:
Obviously this could be refined a bunch from here, but wanted to drop a quick 'half baked solution' here in case it's helpful to anyone either now, or in the future.
Edit: I've also capture the above on the following gist for future reference, and I might edit it to include a more refined version of this process at some point, so worth checking there as well in case: