-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Add suppress-logs flag #4530
Add suppress-logs flag #4530
Conversation
Codecov Report
@@ Coverage Diff @@
## master #4530 +/- ##
==========================================
+ Coverage 72.35% 72.61% +0.25%
==========================================
Files 333 335 +2
Lines 12959 12963 +4
==========================================
+ Hits 9377 9413 +36
+ Misses 2984 2957 -27
+ Partials 598 593 -5
Continue to review full report at Codecov.
|
I saw you mentioned somewhere that we can't repurpose |
I think our goal with this flag is to be able to use it to specify which stages we want to suppress the output of. For example, I would run Currently, |
cmd/skaffold/app/cmd/flags.go
Outdated
@@ -368,6 +368,14 @@ var FlagRegistry = []Flag{ | |||
FlagAddMethod: "BoolVar", | |||
DefinedOn: []string{"render"}, | |||
}, | |||
{ | |||
Name: "suppress-logs", | |||
Usage: "Suppress logs for specified stages in pipeline (build, deploy, status-check)", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to suppress them or shorten them?
Could it just be a "--verbose-logs" that's on by default? I feel it's a bit overkill to be able to change the logs for each stage independently.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dgageot I do think that shorten is probably a better word to use over suppress. As for being able to control each stage independently, do you think that it's overkill from a user's perspective or from an implementation perspective? If from a user's perspective, I think we could support them using =none
or =all
in order to simplify things. This would allow them to not have to deal with per stage settings
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's overkill for the users. But I'm open to other opinions :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@GoogleContainerTools/skaffold-team anyone have thoughts on this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We talked about this in the logging breakout yesterday and it does seem useful to be able to suppress logs from different phases when the phase is successful. This would be helpful for the Cloud Run emulation situation where Skaffold is being used as the mechanism for local building and deploying, but ideally shouldn't be shown to the user.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In that situation, we might want to show the build logs but hide the deploy and status checks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's do that then
Fixes: #4512
Related: #4514, #4515, #4516
Description
This PR simply adds a --suppress-logs flag. It currently has no functionality, but this will be addressed by #4514, #4515, and #4516.
Follow-up Work
The 3 previously mentioned issues will need to be addressed in order to provide functionality.