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

Extend inspect output format with json #113

Merged
merged 3 commits into from
Jan 10, 2024

Conversation

Parthiba-Hazra
Copy link
Contributor

@Parthiba-Hazra Parthiba-Hazra commented Dec 26, 2023

issue: #77

Copy link
Collaborator

@behouba behouba left a comment

Choose a reason for hiding this comment

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

Hi @Parthiba-Hazra, thank you for taking the time to work on this issue. I have added some comments.

json.go Outdated Show resolved Hide resolved
json.go Outdated Show resolved Hide resolved
json.go Outdated Show resolved Hide resolved
Copy link
Member

@snprajwal snprajwal left a comment

Choose a reason for hiding this comment

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

This looks good for the most part, but I'm not too convinced about using a map[string]interface{} for storing the JSON object. interface{} adds a runtime cost to ensure type safety, and might end up having significant overhead for bigger checkpoints. I think marshaling the data in chunks into a json.RawMessage object and doing some string slicing will be considerably more efficient. There's something similar implemented in https://github.com/checkpoint-restore/go-criu/blob/master/crit/image.go#L85-L97, maybe you can check it out and see if that can be used here.

@Parthiba-Hazra
Copy link
Contributor Author

This looks good for the most part, but I'm not too convinced about using a map[string]interface{} for storing the JSON object. interface{} adds a runtime cost to ensure type safety, and might end up having significant overhead for bigger checkpoints. I think marshaling the data in chunks into a json.RawMessage object and doing some string slicing will be considerably more efficient. There's something similar implemented in https://github.com/checkpoint-restore/go-criu/blob/master/crit/image.go#L85-L97, maybe you can check it out and see if that can be used here.

yes you are right, should I go for custom struct instead of interfaces?

@snprajwal
Copy link
Member

snprajwal commented Dec 27, 2023

yes you are right, should I go for custom struct instead of interfaces?

Yes, that would be ideal! The fields that are not populated can be omitted from the final JSON output by marking them with the omitempty attribute.

Copy link
Collaborator

@behouba behouba left a comment

Choose a reason for hiding this comment

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

@Parthiba-Hazra, let's not add fix-up commits. Instead, amend the initial commit or add new self contained commits. This will ensure that that the commit history is clean. Checkout the CRIU contribution guidelines for more details.
It's also a good idea to test the JSON format.

@Parthiba-Hazra
Copy link
Contributor Author

@Parthiba-Hazra, let's not add fix-up commits. Instead, amend the initial commit or make add new self contained commits. This will ensure that that the commit history is clean. Checkout the CRIU contribution guidelines for more details. It's also a good idea to test the JSON format.

sorry if I am wrong but I didn't perform fixup commits, I just added new commits on top of other commits.

@adrianreber
Copy link
Member

The second commit looks indeed like a fixup. You introduce a new feature in the first commit and then you say "minor changes" in the second commit. If you introduce a new feature in one PR you can separate logical changes in different commits but fixups like "minor changes" should be part of the first commit. No need to create a second commit. You can include the fixup in the original commit as long as it is a PR and not yet merged. Once it is merged and it needs to change the situation is different. A commit message like "minor changes" would probably also be questionable and would require a better description of the change.

@Parthiba-Hazra
Copy link
Contributor Author

The second commit looks indeed like a fixup. You introduce a new feature in the first commit and then you say "minor changes" in the second commit. If you introduce a new feature in one PR you can separate logical changes in different commits but fixups like "minor changes" should be part of the first commit. No need to create a second commit. You can include the fixup in the original commit as long as it is a PR and not yet merged. Once it is merged and it needs to change the situation is different. A commit message like "minor changes" would probably also be questionable and would require a better description of the change.

yea got it, sorry for the inconvenience, I just got to know about this fixup commit thing, will keep in my mind for sure. should I create another pr with proper commits?

@snprajwal
Copy link
Member

should I create another pr with proper commits?

Not necessary, you can rebase your branch to fix this. In your case, you need to squash your two recent commits into the oldest commit (extend inspect output format with json). You can do this with the below steps:

  • git rebase -i HEAD~3
  • Change the latest two commits from pick to s or squash in the rebase window
  • Ensure the new commit contains the correct message (by default, git combines the messages of the pick and squash commits)
  • git push --force-with-lease

@Parthiba-Hazra
Copy link
Contributor Author

should I create another pr with proper commits?

Not necessary, you can rebase your branch to fix this. In your case, you need to squash your two recent commits into the oldest commit (extend inspect output format with json). You can do this with the below steps:

  • git rebase -i HEAD~3
  • Change the latest two commits from pick to s or squash in the rebase window
  • Ensure the new commit contains the correct message (by default, git combines the messages of the pick and squash commits)
  • git push --force-with-lease

thanks prajwal for the guidance here, really forgot about squash.

@codecov-commenter
Copy link

codecov-commenter commented Dec 28, 2023

Codecov Report

Attention: 235 lines in your changes are missing coverage. Please review.

Comparison is base (9aa0386) 78.85% compared to head (20d7bfe) 62.96%.

Files Patch % Lines
json.go 0.00% 234 Missing ⚠️
checkpointctl.go 0.00% 1 Missing ⚠️
Additional details and impacted files
@@             Coverage Diff             @@
##             main     #113       +/-   ##
===========================================
- Coverage   78.85%   62.96%   -15.90%     
===========================================
  Files           6        7        +1     
  Lines         927     1161      +234     
===========================================
  Hits          731      731               
- Misses        154      388      +234     
  Partials       42       42               

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link

github-actions bot commented Dec 28, 2023

Test Results

48 tests  ±0   48 ✅ ±0   1s ⏱️ ±0s
 1 suites ±0    0 💤 ±0 
 1 files   ±0    0 ❌ ±0 

Results for commit 20d7bfe. ± Comparison against base commit 9aa0386.

♻️ This comment has been updated with latest results.

Copy link
Member

@rst0git rst0git left a comment

Choose a reason for hiding this comment

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

@Parthiba-Hazra nice work!

json.go Outdated Show resolved Hide resolved
json.go Outdated Show resolved Hide resolved
json.go Outdated Show resolved Hide resolved
json.go Outdated Show resolved Hide resolved
json.go Outdated Show resolved Hide resolved
json.go Outdated Show resolved Hide resolved
json.go Outdated Show resolved Hide resolved
json.go Outdated Show resolved Hide resolved
@adrianreber
Copy link
Member

@Parthiba-Hazra Please take a look at the failed CI results. Also take a look at adding tests. Currently codecov says 0% patch test coverage.

@rst0git rst0git force-pushed the json-output branch 2 times, most recently from 4508754 to 3160ba6 Compare January 10, 2024 19:02
@rst0git rst0git added the bloat-ok Ignore increase in binary size label Jan 10, 2024
This patch extends checkpointctl with support for output in JSON format.

Resolves: checkpoint-restore#77

Signed-off-by: Parthiba-Hazra <[email protected]>
@rst0git rst0git merged commit 2f15c0b into checkpoint-restore:main Jan 10, 2024
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bloat-ok Ignore increase in binary size
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants