-
-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Idea: todo expire todo when PR is released #49
Comments
We could implement a todo-by-ticket github-issues fetcher todo that. This should work for github issues and PRs - these are very similar on github Just enhance the rule implemented with #26 with a new fetcher Since github issue identifiers have a different pattern then jira issue keys, we might need a separate rule |
sadly, what I was thinking seems to be not doable easily: the information of the first git tag which includes the PR, which you can view in GitHub interface, is not exposed in the API. I can't find any easy way to guess this information. |
the refined-github browser extensions renders a note in PRs which have been merged and are part of a PR: you might find some inspiration there |
haha I didn't even know this information was added by this addon, I use it since too much time 😅 they look into this url and hack into the html it seems there is no API equivalent. This solution is a bit hacky: I think there is no BC policy on this type of html url. That why from time to time the add-on has bugs: when GH changes its urls / or html markdown. |
Hmm I would prefer a more api centric approach |
issue/pr closed state handling was implemented with #62 as you pointed out the 'released' state is not easily to determine. until github.com provides a proper mean to detect this state I will close this issue for now. thanks for the feedback though |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Hi!
not sure you'll like this one, as it is a logic suite of #31, but going a little bit further 😅
Something I'd find really useful would be to expire todo comments based on a vendor PR link: when the PR is merged and released, and vendor meets the release version in your dependencies.
I've seen a lot of projects cluttered with comments like this:
// todo: remove this workaround when https://github/vendor/lib/pull/1234 is released
and these todos are only fixed if by chance someone some day sees the comment and gives it some attention.
GitHub exposes in its api the first release when a PR appears. So, I think it could leverage the work done in #32
WDYT?
The text was updated successfully, but these errors were encountered: