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

[RFC] tools: refactor all binary packages as library packages #2983

Open
wants to merge 19 commits into
base: main
Choose a base branch
from

Conversation

mfrw
Copy link
Member

@mfrw mfrw commented May 11, 2022

Request for Comments

Closes: #2982

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

  • The toolchain has been rebuilt successfully (or no changes were made to it)
  • The toolchain/worker package manifests are up-to-date
  • Any updated packages successfully build (or no packages were changed)
  • Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files
  • All package sources are available
  • cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/tools/cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json, .github/workflows/cgmanifest.json)
  • LICENSE-MAP files are up-to-date (./SPECS/LICENSES-AND-NOTICES/data/licenses.json, ./SPECS/LICENSES-AND-NOTICES/LICENSES-MAP.md, ./SPECS/LICENSES-AND-NOTICES/LICENSE-EXCEPTIONS.PHOTON)
  • All source files have up-to-date hashes in the *.signatures.json files
  • sudo make go-tidy-all and sudo make go-test-coverage pass
  • Documentation has been updated to match any changes to the build system
  • Ready to merge

Summary

What does the PR accomplish, why was it needed?
In the current form, all the code in the binary packages is not re-useable to enable building on top of the great work we have.
This PR abstracts all the binary packages as library packages which can be imported in other packages as well to enable code-reuse.
The changes in this PR are 100% backward compatible and it does not break anything. To achieve this, the path of least resistance seemed
to expose a Config structure from the library package and pass all the relevant details that are passed as flags.

Change Log
  • tools: srpmpacker: refactor as a lib instead of a main package
  • tools: specreader: refactor as a lib instead of a main package
  • tools: pkgworker: refactor as a lib instead of a main package
  • tools: graphpkgfetcher: refactor as a lib instead of main package
  • tools: grapher: refactor as a lib instead of main package
  • tools: graphpreprocessor: refactor as a lib instead of main package
  • tools: mv imagegen -> pkg/imagegen
  • tools: imageconfigvalidator: refactor as a lib instead of main package
  • tools: imagepkgfetcher: refactor as a lib instead of main package
  • tools: imager: refactor as a lib instead of main package
  • tools: isomaker: refactor as a lib instead of main package
  • tools: roast: refactor as a lib instead of main package
  • tools: scheduler: refactor as a lib instead of main package
  • tools: liveinstaller: refactor as a lib instead of main package
  • tools: validatechroot: refactor as a lib instead of main package
  • tools: boilerplate: remove un-needed dir
Does this affect the toolchain?

YES

Associated issues
Links to CVEs
  • NA
Test Methodology
  • Local Build

@mfrw mfrw requested a review from a team as a code owner May 11, 2022 09:04
@ghost ghost added Tools main PR Destined for main labels May 11, 2022
@mfrw mfrw added the DevEx Developer Experience label May 11, 2022
@mfrw mfrw requested a review from jslobodzian May 11, 2022 09:52
@mfrw mfrw requested review from dmcilvaney and PawelWMS May 11, 2022 15:34
@christopherco christopherco self-requested a review May 11, 2022 22:16
mfrw added 2 commits May 12, 2022 10:16
The internal directory in Go is a special directory. Any packages inside
the 'internal' directory can't be imported across projects.
This change exposes the 'logger' package as an exportable package.

Signed-off-by: Muhammad Falak R Wani <[email protected]>
The internal directory in Go is a special directory. Any packages inside
the 'internal' directory can't be imported across projects.
This change exposes the 'pkggraph' as an exportable package.

Signed-off-by: Muhammad Falak R Wani <[email protected]>
@mfrw mfrw force-pushed the mfrw/refactor-as-libraries branch from eb0445d to 0583fae Compare May 13, 2022 02:04
Copy link
Contributor

@PawelWMS PawelWMS left a comment

Choose a reason for hiding this comment

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

I love the clean-up done here but would it be possible to split this change into smaller chunks? It's somewhat challenging to review all of this at once while maintaining full focus.

@mfrw
Copy link
Member Author

mfrw commented May 19, 2022

I love the clean-up done here but would it be possible to split this change into smaller chunks? It's somewhat challenging to review all of this at once while maintaining full focus.

The individual commits in the PR are the smaller changes that achieve it.
Given this is such a big refactor, the reason for sending this huge PR is to chunk it as a logical change.
In my opinion, when we merge this, we should do a merge commit rather than a squash-and-merge to save the history.

@mfrw mfrw force-pushed the mfrw/refactor-as-libraries branch from 0583fae to b30d3ab Compare May 21, 2022 05:39
@mfrw mfrw force-pushed the mfrw/refactor-as-libraries branch 2 times, most recently from 4633033 to 202773d Compare August 15, 2022 04:01
ImageTag: *imageTag,
}
}

func main() {
Copy link
Contributor

Choose a reason for hiding this comment

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

Please let's keep main as the first function after the arguments and consts list - I wouldn't want to change that "convention".

app = kingpin.New("boilerplate", "A sample golang tool for Mariner.")

logFile = exe.LogFileFlag(app)
logLevel = exe.LogLevelFlag(app)
Copy link
Contributor

Choose a reason for hiding this comment

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

Why did we remove this one? I believe we were using it as a template for new tooling. If anything, we could update it now to follow your idea of organizing the tools.

// Copyright (c) Microsoft Corporation.
// Licensed under the MIT License.

package hello
Copy link
Contributor

Choose a reason for hiding this comment

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

Since we're removing this piece of code as well (and for good reasons, I believe), the commit message seems to vague. There's no indication this got removed.

"github.com/microsoft/CBL-Mariner/toolkit/tools/internal/safechroot"
)

type fileSignaturesWrapper struct {
Copy link
Contributor

Choose a reason for hiding this comment

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

Just double-checking, because it's hard to tell from the diff (this shows as a brand new file): there are no changes in the code, comments, sections or functions ordering, etc., correct? It's moved 1:1 to a new directory and we're only adding the Config struct?

@@ -122,6 +52,27 @@ var (
signatureHandling = app.Flag("signature-handling", "Specifies how to handle signature mismatches for source files.").Default(signatureEnforceString).PlaceHolder(exe.PlaceHolderize(validSignatureLevels)).Enum(validSignatureLevels...)
)

func populateSrpmPackerConfig() *srpmpacker.Config {
Copy link
Contributor

Choose a reason for hiding this comment

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

Similar request here and all other commits - let's keep main as the first function.

@@ -0,0 +1,249 @@
package grapher
Copy link
Contributor

Choose a reason for hiding this comment

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

Typo in file name grahper.go.

@@ -37,7 +36,7 @@ go_tool_targets = $(foreach target,$(go_tool_list),$(TOOL_BINS_DIR)/$(target))
# Common files to monitor for all go targets
go_module_files = $(TOOLS_DIR)/go.mod $(TOOLS_DIR)/go.sum
go_internal_files = $(shell find $(TOOLS_DIR)/internal/ -type f -name '*.go')
Copy link
Contributor

@PawelWMS PawelWMS Aug 15, 2022

Choose a reason for hiding this comment

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

I'm curious if we still need go_internal_files after all these changes.

}

if err != nil {
logger.Log.Infof("Failed to clone RPM repo. Error: %s", err)
Copy link
Contributor

@PawelWMS PawelWMS Aug 16, 2022

Choose a reason for hiding this comment

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

Why are errors logged on info level now? We can go down to error and make sure the caller does the right thing or keep the original code, like what we did in other commits.

return
cfg := populateImagePkgFetcherConfig()
err := pkgfetcher.FetchPkgsAndCreateRepo(cfg)
logger.PanicOnError(err, "Failed to save cloned repo contents")
Copy link
Contributor

Choose a reason for hiding this comment

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

This looks incorrect now since pkgfetcher.FetchPkgsAndCreateRepo can fail for multiple different reasons.

// the install directory
sshPubKeysTempDirectory = "/tmp/sshpubkeys"
func populateImagerConfig() *imager.Config {
const defaultSystemConfig = 0
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 a duplicate from main and I think you're also not using the SystemConfig field below.

Copy link
Contributor

@PawelWMS PawelWMS left a comment

Choose a reason for hiding this comment

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

I left a few comments. The ones I'm mostly interested in:

  • It seems we're not entirely consistent in how we deal with logger.log.Panic. In most cases we've left them unchanged, which seems fine, since we don't want to change the logic, just refactor, but there's at least one commit where I've seen them converted to logger.log.Info.
  • Related to the above comment: it's insanely difficult to go through all the changes and make sure the logic was not modified. Since the granularity of accepted changes is a whole PR, not separate commits, I'm finding it hard to maintain enough focus to feel safe about approving the whole thing. I'd strongly recommend splitting this into separate PRs to ease with te review process.

@mfrw
Copy link
Member Author

mfrw commented Aug 19, 2022

I left a few comments. The ones I'm mostly interested in:

  • It seems we're not entirely consistent in how we deal with logger.log.Panic. In most cases we've left them unchanged, which seems fine, since we don't want to change the logic, just refactor, but there's at least one commit where I've seen them converted to logger.log.Info.
  • Related to the above comment: it's insanely difficult to go through all the changes and make sure the logic was not modified. Since the granularity of accepted changes is a whole PR, not separate commits, I'm finding it hard to maintain enough focus to feel safe about approving the whole thing. I'd strongly recommend splitting this into separate PRs to ease with te review process.

I appreciate the feedback comments. I think Yes, Let me pluck them one-by-one and try to create seperate PRs for an individual tool, using the same PR. I agree that this is a ginormous PR and reviewing it while keep full focus and not breaking anything is difficult :)

Again appreciate all the reviewers spending time on this PR.

@PawelWMS
Copy link
Contributor

I left a few comments. The ones I'm mostly interested in:

  • It seems we're not entirely consistent in how we deal with logger.log.Panic. In most cases we've left them unchanged, which seems fine, since we don't want to change the logic, just refactor, but there's at least one commit where I've seen them converted to logger.log.Info.
  • Related to the above comment: it's insanely difficult to go through all the changes and make sure the logic was not modified. Since the granularity of accepted changes is a whole PR, not separate commits, I'm finding it hard to maintain enough focus to feel safe about approving the whole thing. I'd strongly recommend splitting this into separate PRs to ease with te review process.

I appreciate the feedback comments. I think Yes, Let me pluck them one-by-one and try to create seperate PRs for an individual tool, using the same PR. I agree that this is a ginormous PR and reviewing it while keep full focus and not breaking anything is difficult :)

Again appreciate all the reviewers spending time on this PR.

Thanks for your understanding, @mfrw! I understand this PR is an immense amount of work on your end. It looks super helpful and IMO close to done, so I'm going to keep an eye out for your updates and help with the review as much as possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
DevEx Developer Experience main PR Destined for main Tools
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants