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

Enhance the transfer-setting command to allow modifying the log level #946

Closed
wants to merge 40 commits into from
Closed

Enhance the transfer-setting command to allow modifying the log level #946

wants to merge 40 commits into from

Conversation

eyalbe4
Copy link
Contributor

@eyalbe4 eyalbe4 commented Sep 12, 2023

Emhance the transfer-setting command to allow modifying the log level while the transfer-files command is running.

Depends on jfrog/jfrog-client-go#828

omerzi and others added 30 commits April 5, 2023 10:15
* Improve UI for scan command (#706)

* Upgrade go version in go.mod to 1.20 (#732)

* Fix lint issues found (#733)

* Config transfer - ensure target not older than source (#721)

* Update tests environment - nuget and dotnet to version 6  (#734)

* Flatten audit graph (#736)

* Use gradle-dep-tree with Audit (#719)

---------

Co-authored-by: Sara Omari <[email protected]>
Co-authored-by: Eyal Ben Moshe <[email protected]>
Co-authored-by: Michael Sverdlov <[email protected]>
Co-authored-by: Yahav Itzhak <[email protected]>
# Conflicts:
#	.github/workflows/analysis.yml
#	go.mod
#	go.sum
#	xray/audit/java/gradle.go
#	xray/commands/audit/generic/auditmanager.go
@eyalbe4 eyalbe4 requested a review from yahavi September 12, 2023 07:13
@yahavi yahavi changed the title Emhance the transfer-setting command to allow modifying the log level Enhance the transfer-setting command to allow modifying the log level Sep 12, 2023
return currLogLevel
}

func (tst *TransferSettingsCommand) validateLogLevelValue(loglevel string) error {
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
func (tst *TransferSettingsCommand) validateLogLevelValue(loglevel string) error {
func (tst *TransferSettingsCommand) validateLogLevelValue(logLevel string) error {

@@ -22,7 +22,8 @@ const (
)

type TransferSettings struct {
ThreadsNumber int `json:"threadsNumber,omitempty"`
ThreadsNumber int `json:"threadsNumber,omitempty"`
LogLevel string `json:"logLevel,omitempty"`
Copy link
Member

Choose a reason for hiding this comment

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

I think it will be safer to work with the same log-level type, using our methods for handling the log levels.

Suggested change
LogLevel string `json:"logLevel,omitempty"`
LogLevel log.LevelType `json:"logLevel,omitempty"`

return err
}
log.Output("The settings were saved successfully. It might take a few moments for the new settings to take effect.")
log.Output(fmt.Sprintf("Note - For Build Info repositories, the number of worker threads will be limited to %d.", utils.MaxBuildInfoThreads))
return nil
}

func (tst *TransferSettingsCommand) getCurrLogLevel(settings utils.TransferSettings) string {
currLogLevel := settings.LogLevel
Copy link
Contributor

Choose a reason for hiding this comment

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

Missing a check if settings != nil here.

}

func (tst *TransferSettingsCommand) validateLogLevelValue(loglevel string) error {
if loglevel != "DEBUG" && loglevel != "INFO" && loglevel != "WARN" && loglevel != "ERROR" {
Copy link
Contributor

Choose a reason for hiding this comment

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

I suggest a cleaner approach:

	switch loglevel {
	case "DEBUG", "INFO", "WARN", "ERROR":
		return nil
	default:
		return errorutils.CheckErrorf("the log level value is invalid")
	}

if err := updateThreads(pcWrapper, buildInfoRepo); err != nil {

settings, err := utils.LoadTransferSettings()
if err != nil || settings == nil {
Copy link
Contributor

Choose a reason for hiding this comment

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

We should not return if settings is nil, we should continue. Settings file does not exist on a clean run, until it is created with the settings command.

So far we also didn't return here if an error occurred. Our approach was to log it and not stop the transfer due to an error in the settings. If we decide to change approach, we should change it in all relevant places.

In addition, only log the error if it is not nil, this currently logs the error also when both the settings and error is nil.

@eyalbe4 eyalbe4 closed this Oct 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants