Skip to content
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

New functions git.GetUserName and git.GetUserEmail #1453

Merged
merged 1 commit into from
Aug 5, 2020

Conversation

puerco
Copy link
Member

@puerco puerco commented Aug 1, 2020

What type of PR is this?

/kind api-change
/kind feature

What this PR does / why we need it:

This PR introduces two new functions to the got package: git.GetUserName and git.GetUserEmail to be able to get the user's information outside of the git package.

Tests for both functions are included in the git_test.go file

Which issue(s) this PR fixes:

Special notes for your reviewer:

Test for the functions will create an empty git repository, configure it with the user's data and call the functions in the git package.

Does this PR introduce a user-facing change?

New standaolne functions `git.GetUserName()` and `git.GetUserEmail()`

Signed-off-by: Adolfo García Veytia [email protected]

@k8s-ci-robot k8s-ci-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API kind/feature Categorizes issue or PR as related to a new feature. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. needs-priority size/L Denotes a PR that changes 100-499 lines, ignoring generated files. area/release-eng Issues or PRs related to the Release Engineering subproject labels Aug 1, 2020
@k8s-ci-robot k8s-ci-robot added the sig/release Categorizes an issue or PR as relevant to SIG Release. label Aug 1, 2020
@@ -64,6 +67,84 @@ func TestGetDefaultKubernetesRepoURLSuccess(t *testing.T) {
}
}

// createTestRepository creates a test repo, cd into it and returns the path
func createTestRepository() (repoPath string, err error) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can newSUT() be reused here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I considered it, but I figured that instead of looking into only simulating the call by regenerating the fakes with counterfeiter (and possibly getting myself into a mess) it would be better to do a function that actually calls git in a repo. Do you think I should go with the simulated tests? (can do, no problem :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok I've delved a bit into this. Currently, there is no way to use newSUT() as the function only creates a mock Repository interface for the tests and most of the calls to git call the command package directly.

I was thinking about how to add the command fakes to the git package following @saschagrunert 's advice and we would have to something like this:

  1. Add a new interface to interface (duh) with the command package. CommandCaller or something like that.
  2. Replace all calls to command.* in the git package to go through this interface.
  3. Create the mock CommandCaller in the tests and then rewrite the tests with it.

What do you think @hasheddan @saschagrunert ? If this sounds good to you, I can rework the package later this week.

@fejta-bot
Copy link

This PR may require API review.

If so, when the changes are ready, complete the pre-review checklist and request an API review.

Status of requested reviews is tracked in the API Review project.

Copy link
Member

@saschagrunert saschagrunert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Other than previous comments, just one general nit. Otherwise LGTM. :)

@puerco puerco force-pushed the git-userdata-funcs branch from e43f46a to ec05406 Compare August 4, 2020 00:41
@puerco
Copy link
Member Author

puerco commented Aug 4, 2020

/test pull-release-test
(timed out)

Copy link
Member

@saschagrunert saschagrunert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm
/hold
For the discussion https://github.com/kubernetes/release/pull/1453/files#r463996463
Feel free to lift the hold if we wanna follow-up on this one.

@k8s-ci-robot k8s-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Aug 4, 2020
@k8s-ci-robot k8s-ci-robot added lgtm "Looks good to me", indicates that a PR is ready to be merged. approved Indicates a PR has been approved by an approver from all required OWNERS files. labels Aug 4, 2020
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: puerco, saschagrunert

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@puerco
Copy link
Member Author

puerco commented Aug 5, 2020

OK, in order to make the tests all similar I'll start looking into creating a mock of the Command calls in the near future. Meanwhile in it goes.
/cc @hasheddan
/hold cancel

@k8s-ci-robot k8s-ci-robot requested a review from hasheddan August 5, 2020 16:08
@k8s-ci-robot k8s-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Aug 5, 2020
@k8s-ci-robot k8s-ci-robot merged commit 8f704f8 into kubernetes:master Aug 5, 2020
@k8s-ci-robot k8s-ci-robot added this to the v1.19 milestone Aug 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. area/release-eng Issues or PRs related to the Release Engineering subproject cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API kind/feature Categorizes issue or PR as related to a new feature. lgtm "Looks good to me", indicates that a PR is ready to be merged. needs-priority release-note Denotes a PR that will be considered when it comes time to generate release notes. sig/release Categorizes an issue or PR as relevant to SIG Release. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants