Conversation
added 2 commits
February 12, 2020 15:04
gzussa
requested review from
bkabrda,
jirikuncar,
nmuesch and
zippolyte
as code owners
February 13, 2020 13:43
6 tasks
zippolyte
suggested changes
Feb 21, 2020
Comment on lines
+377
to
+391
| if(StringUtils.isNotBlank(portStr)){ | ||
| if(StringUtils.isNumeric(portStr)) { | ||
| this.setTargetPort(formData.getInt("targetPort")); | ||
| } | ||
| }else{ | ||
| this.setTargetPort(null); | ||
| } | ||
| String logCollectionPortStr = formData.getString("targetLogCollectionPort"); | ||
| if(StringUtils.isNotBlank(logCollectionPortStr)){ | ||
| if(StringUtils.isNumeric(logCollectionPortStr)){ | ||
| this.setTargetLogCollectionPort(formData.getInt("targetLogCollectionPort")); | ||
| } | ||
| }else{ | ||
| this.setTargetLogCollectionPort(null); | ||
| } |
Contributor
There was a problem hiding this comment.
isn't it supposed to be validated by validateTargetPort ?
Contributor
Author
There was a problem hiding this comment.
yes and it is happening below.
Contributor
There was a problem hiding this comment.
I guess I don’t understand why we do the type checking here as well
zippolyte
approved these changes
Feb 21, 2020
|
@gzussa |
Contributor
Author
| DatadogUtilities.severe(logger, null, String.format("Datadog/%s/jenkins Java/%s Jenkins/%s", | ||
| getDatadogPluginVersion(), | ||
| getJavaRuntimeVersion(), | ||
| getJenkinsVersion())); |
Contributor
There was a problem hiding this comment.
Definitely not and still on master, I'll remove it now 👍
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Adding log collection and better exception logging when the plugin is misconfigured.
Description of the Change
Created a package to hold the log logic. It contains 3 classes:
DatadogConsoleLogFilterthat extendsConsoleLogFilter. All it does is decorate the log outputStream with a customDatadogOutputStreamif needed.DatadogOutputStreamextendsLineTransformationOutputStreamand mainly clean log lines from Jenkins Notes. It then uses aDatadogWriterclass to submit logs.DatadogWritergets contextual information to prepare the log message to be sent to Datadog.BuildDatain order to be able to retrieve a maximum of tags/contextual info even when a listener is not provided to the constructor. In turn, i had to make changes to some methods inDatadogUtilitiesin order to be more permissive.Added new configs:
logIntakeUrlwhen submitting log using the Datadog API directly.logCollectionPortwhen submitting log using the Datadog Agent.collectBuildLogsto turn the collection on and off (default is off).Env variable loading is not overriding the saved config anymore, hence simplifying the loading logic a little.
I also made changes regarding exception loggings. Before, if the plugin was misconfigured it would print out stack trace exceptions in stdout. It would do so repetitively because of all Publisher classes.
We no longer throw exceptions when calling
getInstanceon a client implementation.Even if params are not valid (null or empty), we return null. As a consequence, I had to add null checks everywhere in order to return from the calling method. Now user will see clean severe level error message in their logs.
I also added connection broken attributes (
defaultIntakeConnectionBrokenandlogIntakeConnectionBroken) in order to prevent making bad http calls to Datadog all the time and especially when we know the connection is broken after validation.As a consequence, i had to refactor the
validatehttp client method is order to be static and independent from the current client instance singleton.Possible Drawbacks
When enable, log submission may have some perf implications but i haven't done any load testing at this point and it is kinda inevitable anyway.
Verification Process
Review and manual testing mainly.
Review checklist (to be filled by reviewers)
changelog/label attached. If applicable it should have thebackward-incompatiblelabel attached.do-not-merge/label attached.kind/andseverity/labels attached at least.