-
-
Notifications
You must be signed in to change notification settings - Fork 849
Drop Project-and-Username-finding code #451
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
Drop Project-and-Username-finding code #451
Conversation
e5487ad
to
06c5ac1
Compare
@@ -0,0 +1,120 @@ | |||
# frozen_string_literal: true | |||
module GitHubChangelogGenerator | |||
class ProjectNameFinder |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find that trying to write a class level comment often helps with finding a fitting name. What purpose does this class serve, how does one use it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This class interrogates given CLI options and Git remotes to parse out a GitHub username and a project name, the two parts of what's usually called a GitHub repo slug.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, makes sense. Sounds a bit like it does two different things that are not even so related: interrogating options on the one hand, parsing a remote on the other hand. Only the thing that comes out of it is the same.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm also not excited about placing the test data (the default) inside this implementation.
I'll add "turning the default user/project repo slug into some kind of test setup".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And I agree with this being two things.
[Regexp.last_match(:user), Regexp.last_match(:project)] | ||
end | ||
end | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Forgive me if I've overlooked something, since I'm only looking at this diff right now - but is this method and the following ones only public in order to support being called from the spec? In that case, it might be worth some effort trying to make them private I think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think so, too. This is not a part of the usable interface.
Coming up for air after a long dive into this, I now find that I only want to remove this section of the code-base and have an easier time. It's even easier to explain the thing when the I will update this PR with changes to that effect. |
06c5ac1
to
81851f9
Compare
Ah, like a fine wine, this change has matured over the long summer. Now I have made the change that I learned I wanted: code deletion. |
This is needed since github-changelog-generator/github-changelog-generator#451 was merged.
This is needed since github-changelog-generator/github-changelog-generator#451 was merged.
@olleolleolle Is this considered a breaking change from the 1.14.x series? Should the next release be a 2.0.0 instead of a 1.15.0 (not counting the alpha/beta/pre releases)? (There are many dramatic changes, but this may be the only breaking change that isn't technically a bugfix.) |
If we could reimplement the feature with new code, perhaps we stand a better chance of making it work well? |
PR github-changelog-generator#451 removes the repo-guessing code, which both: * allows the user and project to be set in the Rake task * *requires* the user and project to be set in the Rake task update the Rake example in the README to reflect this new usage
This PR is a refactoring to extract a large section of unrelated-to-option-parsing code from the option parser.- [ ] improve extracted class name - is RepoSlugParser better?- [ ] pore over the specs, esp. the final one, which seems fishy- [ ] perhaps find a better way to express the "list of strategies" in the new class (#call
)- [ ] turn the default user/project repo slug into some kind of test setupUpdate: We did none of those things, we looked long and hard at it, and decided that it would be easier to drop the functionality.