-
-
Notifications
You must be signed in to change notification settings - Fork 9k
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
[JENKINS-52692,JENKINS-38313] - External task logging API #3557
[JENKINS-52692,JENKINS-38313] - External task logging API #3557
Conversation
…bmissions from Elasticsearch
Hide launcher complexity from plugin.
…-task-logging-poc # Conflicts: # core/src/main/java/hudson/model/AbstractProject.java # core/src/main/java/hudson/model/Job.java # core/src/main/java/hudson/model/Run.java
# Conflicts: # core/src/main/java/hudson/model/Job.java # core/src/main/java/hudson/model/Run.java
…sisted for Runs + extend API
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.
Some initial comments from a brief look. I expect to go back over this in detail.
@@ -292,7 +292,7 @@ public static void skip(DataInputStream in) throws IOException { | |||
} | |||
|
|||
private static final long serialVersionUID = 1L; | |||
|
|||
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.
Revert please.
/** | ||
* Returns charset to be used. | ||
* New implementations are recommended to use {@code UTF-8}-only (default), | ||
* but the method can be overridden by legacy implementations. |
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 feel that this unnecessarily complicates the system, adding to the conceptual burden. There are no “legacy implementations” of a brand-new API. If you are referring to freestyle build logs, now is the time to fix them, like we did for Pipeline in JEP-206.
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.
Cc @Casz who also wanted to get rid of non-UTF-8 logging iirc
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 concur with jesse.
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.
Current design: https://github.com/jenkinsci/jep/tree/master/jep/207#encoding-of-log-files
Currently Jenkins does not set limitations for encoding while doing logging. Any charsets may be used on agent and master sides, and it is hard to manage them.
Although it is expected that all logs eventually switch to UTF-8 (see the JEP-206 proposal for Pipeline), in meantime external logging may be performed in different encodings.
* Loggable implementations can define the charset to be used
* Logging Method and Logging Browser implementations may implement support of charsets or reject them, it is up to the implementation
* If the implementation does not support a charset, `ExternalLoggingMethodLocator` can skip the logging method
I believe this is a more conservative approach. I do not want to fix Freestyle logging in this change, because it may introduce serious regressions.
If you prefer, I could add a supportsNonUTF8()
method (defaults to false
) so that LoggingMethodLocator
checks support automatically.
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 do not want to fix Freestyle logging in this change, because it may introduce serious regressions.
Well, the same could be said for JEP-206, but my feeling was that it was worth risking regressions in the interest of making the system design simpler and clearer in the long run.
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.
(see #3231)
* @return Temporary directory or {@code null} if not defined | ||
*/ | ||
@CheckForNull | ||
default File getTmpDir() { |
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.
What would override this and to what value? Seems YAGNI
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.
Yes, it's YAGNI after the today's refactoring
import java.util.List; | ||
|
||
/** | ||
* Defines how the logs should be browsed. |
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 do not think it makes sense to split this from LogMethod
. While for certain implementations of external log storage there may be multiple potential browsers that we would like to allow users to select independently, I would not expect that to be universally true, and at worst such implementations could define their own extension point.
It seems that the only actual extension point so far is LoggingMethodLocator
, so what is the purpose of separating these interfaces?
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.
Please comment in JEP instead: https://github.com/jenkinsci/jep/tree/master/jep/207#why-loggingmethod-and-logbrowser-are-separated
@@ -2129,7 +2130,7 @@ public void setCustomWorkspace(String customWorkspace) throws IOException { | |||
this.customWorkspace= Util.fixEmptyAndTrim(customWorkspace); | |||
save(); | |||
} | |||
|
|||
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.
Revert please.
} | ||
|
||
@Exported | ||
public String getId() { |
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.
What is this used for? I would drop it. Stapler exporting already specifies _class
where required.
/** | ||
* Gets log for a part of the object. | ||
* @param stepId Identifier of the step to be displayed. | ||
* It may be Pipeline step or other similar abstraction |
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.
Why does this need to be defined here? Seems like it belongs only in external-logging-api
.
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.
"Steps" may exist for custom logging implementations , eventually not only for Pipeline. So I would prefer to keep API here at lower level
* @since TODO | ||
*/ | ||
@Restricted(Beta.class) | ||
public class CloseableStreamBuildListener extends StreamBuildListener implements Closeable { |
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.
Huh? StreamTaskListener
is already Closeable
.
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.
Yes, to be deleted at all
|
||
/** | ||
* Defines an additional Console Log Filter to be used with the logging method. | ||
* This filter may be also used for log redirection and multi-reporting in very custom cases. |
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.
Explain?
final Job<?, ?> project = build.getParent(); | ||
|
||
// Project specific log filters | ||
if (project instanceof BuildableItemWithBuildWrappers && build instanceof AbstractBuild) { |
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.
This looks like a failure of abstraction.
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.
It is. But this is an exisiting code, just moved it. Happy to add TODO and follow-up JIRA
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 see, did not notice this was moved out of Run
.
@jglick if we merge LogBrowser and LoggingMethod, would you be fine with the |
(At least in core—not necessarily in
Yes that sounds sensible. In such a case jenkinsci/workflow-api-plugin#17 might be better renamed to |
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 discussed some planned changes. Taking off my review queue for now.
The fact that the Incrementals notification is green when deployment fails is totally confusing. There is a ticket for that somewhere
|
…ation to External logging API
Given this PR is conflicted, and Oleg has himself marked this as Oleg, please obviously feel free to reopen anytime if you feel like it. Thanks! |
See JENKINS-52692. This pull request is a WiP set of changes for the External Build Loggin JEP which will be submitted soon. It includes the External Logging Prototype created back in 2016 together with @xyan0607 + new API changes I am doing to reflect the current design.
Downstream pull requests:
Proposed changelog entries
Submitter checklist
* Use the
Internal:
prefix if the change has no user-visible impact (API, test frameworks, etc.)Desired reviewers
@mention