feat(github): support #discussioncomment-
urls
#266
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adds support for embedding
<owner>/<repo>/discussions/<id>#discussioncomment-<id>
urls.This is... rather difficult via the GraphQL api (which you are required to use for this :/), since you would need the global ID (
DC_kwDOF-MrcM4AT8ii
), which you can technically only get from prior API requests.The other "intended" way of fetching a discussion comment based on the integer ID would be to query
discussion(123) { comments(after: ...) {}}
and paginate through all comments until we find a matching ID. no thanks.Instead, we rely on the undocumented format of GraphQL global IDs, which are msgpack'ed arrays containing the repo ID and resource ID, with a type prefix. This works with essentially any resource, e.g.
I_{b64(msgpack([0, repo_id, issue_id]))}
to fetch an issue based on its ID, and so on; the prefixes are pretty trivial to figure out.It's worth noting that these IDs also include an owner ID (i.e.
repo_id
above), which we don't get from the URL. This ID isn't required atm, but may be in the future. As per GHE source:It works fine for now, and this ID format hasn't changed for the 4 years it has been used so far. If it does end up being required in the future, we'll have to make one extra API request to turn the
<owner>/<repo>
part from the URL into an ID as well.(the timestamp was wrong, see #240.)