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

feat: commit and push changes onto a SHA to a target remote #30

Merged
merged 13 commits into from Jul 17, 2020

Conversation

TomKristie
Copy link
Contributor

This PR implements the basic functionality of creating GitHub trees, a commit for that tree, and updating the latest reference HEAD to point to that tree. It also has basic mock tests.

Given:

  • current reference HEAD
  • an owner
  • a repository
  • a branch name
  • changes
  • commit message

On success, create a tree with those changes, a commit pointing to that tree, and update the reference branch HEAD to point to that new commit.
On error re-throw Octokit Error.

Towards #19

@TomKristie TomKristie requested a review from a team as a code owner July 13, 2020 23:25
@codecov
Copy link

codecov bot commented Jul 13, 2020

Codecov Report

Merging #30 into master will increase coverage by 54.17%.
The diff coverage is 97.34%.

Impacted file tree graph

@@             Coverage Diff             @@
##           master      #30       +/-   ##
===========================================
+ Coverage   37.28%   91.46%   +54.17%     
===========================================
  Files           3        9        +6     
  Lines          59      586      +527     
  Branches        0       26       +26     
===========================================
+ Hits           22      536      +514     
- Misses         37       50       +13     
Impacted Files Coverage Δ
src/github-handler/index.ts 0.00% <0.00%> (ø)
src/logger/index.ts 0.00% <0.00%> (ø)
src/github-handler/fork-handler.ts 98.07% <98.07%> (ø)
src/github-handler/branch-handler.ts 98.91% <98.91%> (ø)
src/github-handler/commit-and-push-handler.ts 98.98% <98.98%> (ø)
src/github-handler/pr-handler.ts 100.00% <100.00%> (ø)
src/types/index.ts 100.00% <100.00%> (ø)
... and 3 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f268414...6649350. Read the comment docs.

src/types/index.ts Outdated Show resolved Hide resolved
function genTreeObj(changes: Changes): GitCreateTreeParamsTree[] {
const tree: GitCreateTreeParamsTree[] = [];
for (const path in changes) {
if (!path) continue;
Copy link
Contributor

Choose a reason for hiding this comment

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

When would path be unset?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It should never be. This is more of a TypeScript stylistic thing I've seen. I will remove it!

src/github-handler/commit-and-push-handler.ts Outdated Show resolved Hide resolved
const tree: GitCreateTreeParamsTree[] = [];
for (const path in changes) {
if (!path) continue;
if (changes[path].content) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Is "" string truthy? If I want an empty string (a.k.a. an empty file), will this instead delete the file?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes it would. I'll fix that to allow empty files.

src/github-handler/commit-and-push-handler.ts Outdated Show resolved Hide resolved
src/github-handler/commit-and-push-handler.ts Outdated Show resolved Hide resolved
}

interface FileData {
mode: FileMode;
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we expect all change sources to include the file mode or should it be optional with a default value?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think it's a great idea. The only downside I can see is that we will diverge from the Octokit/GitHub v3 api design where there is no default value. However users don't need to know that we use Octokit - just our interface, so there shouldn't be a problem.

Comment on lines 24 to 26
path?: string;
mode?: FileMode;
type?: 'blob' | 'tree' | 'commit';
Copy link
Contributor

Choose a reason for hiding this comment

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

Looks like these are always present?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The ? matches the Octokit type definition exactly right now, but I'll change it to support our needs more.

@chingor13
Copy link
Contributor

In general, we still want to camel case abbreviations (e.g. headSha, somethingHead)

@TomKristie TomKristie added the type: process A process-related concern. May include testing, release, or the like. label Jul 14, 2020
@TomKristie TomKristie added this to the Open-PR-From-Fork milestone Jul 14, 2020
test/commit-and-push.ts Outdated Show resolved Hide resolved
src/github-handler/commit-and-push-handler.ts Outdated Show resolved Hide resolved
* @returns {Promise<string>} the GitHub tree SHA
*/
async function createTree(
logger: Logger,
Copy link
Contributor

Choose a reason for hiding this comment

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

Question for later/refactor: do we expect the logger to be a singleton (which we can import directly from the module) or do we want to pass an instance around everywhere?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think it might depend on whether or not we foresee child logging. It is currently read-only and there currently is no child-logging so it would work. The only downside is that we would write to a global during setup. I'm not sure what best practices are for that

Copy link
Contributor

Choose a reason for hiding this comment

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

This is non-blocking on this PR, but something to consider before 1.0.0 as it probably affects the interface of all the methods we are exporting

Copy link
Contributor

@chingor13 chingor13 left a comment

Choose a reason for hiding this comment

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

Code generally LGTM - just a few changes on the structure of the tests

Comment on lines 180 to 185
beforeEach(() => {
stubGetCommit.restore();
stubCreateTree.restore();
stubCreateCommit.restore();
stubUpdateRef.restore();
});
Copy link
Contributor

Choose a reason for hiding this comment

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

It's a bit of an odd pattern to have a globally set initial stub, then restore in the beforeEach/setup. Normally, you would do stubbing in the before (or in the test) and clean it up in the teardown.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is an outdated commit and there's no longer a globally set initial stub. All the stubs are local now. The new behaviour is making sure each test has a clean runtime environment by doing sinon.restore()

Comment on lines 27 to 33
const changes: Changes = new Map();
changes.set('a/foo.txt', new FileData('Foo content'));
changes.set('b/bar.txt', new FileData(null));
changes.set('baz.exe', new FileData(null, '100755'));
changes.set('empty.txt', new FileData(''));

const tree: TreeObject[] = [
Copy link
Contributor

Choose a reason for hiding this comment

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

Unless these are used across multiple tests within the describe block, but it into the test that uses this test data.

Comment on lines 46 to 57
{
path: 'baz.exe',
mode: '100755',
type: 'blob',
sha: null,
},
{
path: 'empty.txt',
mode: '100644',
type: 'blob',
content: '',
},
Copy link
Contributor

Choose a reason for hiding this comment

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

Since you're exporting generateTreeObjects, I might separate each test/edge case for the input file -> TreeObject. That way it's more explicit that a FileData with null|empty content should create certain TreeObjects.

Otherwise, you're only testing then entire createTree method which could fail for multiple reasons (and makes it harder to debug). But say that both the createTree test and a test for null content fails, then it's easier to deduce that the null content bug is failing both tests.

src/github-handler/commit-and-push-handler.ts Show resolved Hide resolved
@chingor13 chingor13 added the automerge Merge the pull request once unit tests and other checks pass. label Jul 17, 2020
@gcf-merge-on-green gcf-merge-on-green bot merged commit 8bf1782 into master Jul 17, 2020
@gcf-merge-on-green gcf-merge-on-green bot deleted the basic-commit-and-push branch July 17, 2020 16:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
automerge Merge the pull request once unit tests and other checks pass. type: process A process-related concern. May include testing, release, or the like.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants