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

[JENKINS-52692,JENKINS-38313] - External task logging API #3557

Closed

Conversation

oleg-nenashev
Copy link
Member

@oleg-nenashev oleg-nenashev commented Jul 23, 2018

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

  • Entry 1: Issue, Human-readable Text
  • ...

Submitter checklist

  • JIRA issue is well described
  • Changelog entry appropriate for the audience affected by the change (users or developer, depending on the change). Examples
    * Use the Internal: prefix if the change has no user-visible impact (API, test frameworks, etc.)
  • Appropriate autotests or explanation to why this change has no tests
  • For dependency updates: links to external changelogs and, if possible, full diffs

Desired reviewers

@mention

@oleg-nenashev oleg-nenashev self-assigned this Jul 23, 2018
@oleg-nenashev oleg-nenashev added the work-in-progress The PR is under active development, not ready to the final review label Jul 23, 2018
@jglick jglick self-requested a review July 23, 2018 17:35
Copy link
Member

@jglick jglick left a 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;

Copy link
Member

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.
Copy link
Member

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.

Copy link
Member Author

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

Copy link
Member

Choose a reason for hiding this comment

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

I concur with jesse.

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Member

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() {
Copy link
Member

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

Copy link
Member Author

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.
Copy link
Member

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?

Copy link
Member Author

Choose a reason for hiding this comment

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

@@ -2129,7 +2130,7 @@ public void setCustomWorkspace(String customWorkspace) throws IOException {
this.customWorkspace= Util.fixEmptyAndTrim(customWorkspace);
save();
}

Copy link
Member

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() {
Copy link
Member

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
Copy link
Member

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.

Copy link
Member Author

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 {
Copy link
Member

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.

Copy link
Member Author

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.
Copy link
Member

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) {
Copy link
Member

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.

Copy link
Member Author

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

Copy link
Member

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 jglick self-requested a review July 23, 2018 19:08
@oleg-nenashev
Copy link
Member Author

@jglick if we merge LogBrowser and LoggingMethod, would you be fine with the LogStorage name?

@oleg-nenashev oleg-nenashev mentioned this pull request Jul 25, 2018
4 tasks
@jglick
Copy link
Member

jglick commented Jul 25, 2018

if we merge LogBrowser and LoggingMethod

(At least in core—not necessarily in external-logging-api.)

would you be fine with the LogStorage name?

Yes that sounds sensible. In such a case jenkinsci/workflow-api-plugin#17 might be better renamed to PipelineLogStorage. It is related but not identical.

Copy link
Member

@jglick jglick left a 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.

@oleg-nenashev
Copy link
Member Author

oleg-nenashev commented Jul 31, 2018

The fact that the Incrementals notification is green when deployment fails is totally confusing. There is a ticket for that somewhere

Skipping deployment as no artifacts were found with the expected path, typically due to a PR merge build not up to date with its base branch: https://ci.jenkins.io/job/Core/job/jenkins/job/PR-3557/6/artifact/**/*-rc*.f56ea7aafcaa/*-rc*.f56ea7aafcaa*/*zip*/archive.zip

@oleg-nenashev oleg-nenashev added stalled The PR is reasonable and might be merged, but it is no longer active. It can be taken over by other and removed work-in-progress The PR is under active development, not ready to the final review labels Feb 1, 2019
@batmat batmat added the unresolved-merge-conflict There is a merge conflict with the target branch. label Apr 4, 2019
@batmat
Copy link
Member

batmat commented Apr 4, 2019

Given this PR is conflicted, and Oleg has himself marked this as stalled, I am going to close it.

Oleg, please obviously feel free to reopen anytime if you feel like it.

Thanks!

@batmat batmat closed this Apr 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stalled The PR is reasonable and might be merged, but it is no longer active. It can be taken over by other unresolved-merge-conflict There is a merge conflict with the target branch.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants