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-45864] Add SCM instance attribute to ChangeLogSet #2955

Closed
wants to merge 8 commits into from

Conversation

thatrevguy
Copy link

@thatrevguy thatrevguy commented Jul 31, 2017

See JENKINS-45864.

@jenkinsci/code-reviewers

@daniel-beck daniel-beck changed the title Add SCM instance attribute to ChangeLogSet [JENKINS-45864] Add SCM instance attribute to ChangeLogSet Jul 31, 2017
@daniel-beck
Copy link
Member

@abayer Didn't you recently build something related?

Copy link
Member

@oleg-nenashev oleg-nenashev left a comment

Choose a reason for hiding this comment

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

The change looks good to me, my comments are mostly about better diagnosability and static analysis

@@ -42,6 +42,17 @@
public abstract class ChangeLogParser {

/**
* @since
Copy link
Member

Choose a reason for hiding this comment

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

@since TODO is better

if (build instanceof AbstractBuild && Util.isOverridden(ChangeLogParser.class, getClass(), "parse", AbstractBuild.class, SCM.class, File.class)) {
return parse((AbstractBuild) build, scm, changelogFile);
} else {
throw new AbstractMethodError("You must override the newer overload of parse");
Copy link
Member

Choose a reason for hiding this comment

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

"... to support non-Pipeline jobs".

Ideally we need a @RequireOverride annotation to make these cases explicit during the compilation/static analysis

@@ -53,6 +64,11 @@
}

@Deprecated
public ChangeLogSet<? extends Entry> parse(AbstractBuild build, SCM scm, File changelogFile) throws IOException, SAXException {
Copy link
Member

Choose a reason for hiding this comment

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

Makes sense to add Javadoc and to document why

@@ -61,6 +61,17 @@
@Deprecated
public final AbstractBuild<?,?> build;
private final RepositoryBrowser</* ideally T */?> browser;
private final SCM scm;
Copy link
Member

Choose a reason for hiding this comment

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

Add @CheckForNull annotation

@@ -69,6 +80,7 @@ protected ChangeLogSet(Run<?,?> run, RepositoryBrowser<?> browser) {
this.run = run;
build = run instanceof AbstractBuild ? (AbstractBuild) run : null;
this.browser = browser;
this.scm = null;
Copy link
Member

Choose a reason for hiding this comment

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

Use this(run, browser, null) to avoid code duplication

* Repository SCM of this change set.
* @return a SCM instance or null.
*/
public SCM getSCM() { return scm; }
Copy link
Member

Choose a reason for hiding this comment

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

Add @CheckForNull

/**
* @since
*/
protected ChangeLogSet(Run<?,?> run, RepositoryBrowser<?> browser, SCM scm) {
Copy link
Member

Choose a reason for hiding this comment

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

Nice2have, document parameters, add argument annotations

@@ -52,6 +63,16 @@
}
}

/**
* Method for compatibility with AbstractBuild.
Copy link
Member

Choose a reason for hiding this comment

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

I would just say, @deprecated this method should not be used directly anymore, use the {@link ...} method instead. Should not override annotation may be helpful as well (@Restricted(ProtectedExternally.class) )

Copy link
Author

@thatrevguy thatrevguy Aug 2, 2017

Choose a reason for hiding this comment

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

A little confused on how AbstractBuild will behave when it runs this.

If a SCM plugin only overrides the Run based parse function will AbstractBuild run it or still revert to AbstractBuild based parse function?

Guessing it would go for the latter function. Which would require an override to populate SCM attribute on ChangeLogSet produced from AbstractBuild. Otherwise we are stuck in a catch 22 situation.

Preferably, the AbstractBuild based parse function would execute:
return parse((Run) build, scm, changelogFile);

But no SCM plugins implement this yet.

Copy link
Member

Choose a reason for hiding this comment

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

This is a good point. Maybe it makes sense to name the new method as parseRun() to prevent ambiguity. Then all internal calls may be safely moved to the new method

* @since TODO
*/
public ChangeLogSet<? extends Entry> parseRun(Run build, SCM scm, File changelogFile) throws IOException, SAXException {
if (build instanceof AbstractBuild && Util.isOverridden(ChangeLogParser.class, getClass(), "parse", AbstractBuild.class, SCM.class, File.class)) {
Copy link
Member

Choose a reason for hiding this comment

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

Method renamed, also AME below needs adapting.

* ChangeLogSet SCM attribute in AbstractBuild projects.
*/
@Deprecated
public ChangeLogSet<? extends Entry> parseRun(AbstractBuild build, SCM scm, File changelogFile) throws IOException, SAXException {
Copy link
Member

Choose a reason for hiding this comment

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

I would rather keep it as just "parse()" since it is not Run. Renaming both methods didn't help to avoid ambiguity I was referencing before

@oleg-nenashev oleg-nenashev added the needs-more-reviews Complex change, which would benefit from more eyes label Aug 4, 2017
@oleg-nenashev
Copy link
Member

Would be nice to get it in the weekly so it would have a chance to get into the next LTS baseline

@daniel-beck
Copy link
Member

Would prefer this gets a proper review to ensure the additions are sane.

@oleg-nenashev oleg-nenashev added the on-hold This pull request depends on another event/release, and it cannot be merged right now label Aug 5, 2017
@oleg-nenashev
Copy link
Member

@daniel-beck put it on hold

@oleg-nenashev
Copy link
Member

@daniel-beck seems it's going to miss the weekly. Would be great if you find some time to review it before the next one

@daniel-beck daniel-beck self-assigned this Aug 12, 2017
@thatrevguy
Copy link
Author

Hello, anything else needed from me at this point?

@daniel-beck
Copy link
Member

@hathoward No, thanks for checking in. Jenkins World has been sucking up our time the last few weeks, so this has been delayed.

Copy link
Member

@oleg-nenashev oleg-nenashev left a comment

Choose a reason for hiding this comment

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

The updated version LGTM, needs re-review by @daniel-beck

@daniel-beck
Copy link
Member

Would be more comfortable if @jglick could take a look at this.

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.

Does not seem like a good idea. Adding a new persistent field to ChangeLogSet may or may not be desirable (would need to consider the XStream-serialized form). At least, on its own it does not address the stated goal

a reliable way to identify correct remote URL for a ChangeLogSet instance

which based on the references to the git plugin I presume refers to Git changelogs. It is also unclear from JIRA what kind of report is needed—in the UI? Via Stapler exported …/api/json? Solely via Java API?

In any event there is no apparent downstream PR showing how this would be used, by git-plugin, or the reporter’s

plugin for handling deployment COs

Certainly it would need at a minimum some kind of new call for Pipeline, thus a PR using timestamped snapshots in workflow-job-plugin, and some sort of functional test demonstrating the newly available information being used successfully.

It is not even obvious to me that any core API change is needed here at all. There is nothing preventing an implementation of SCM.createChangeLogParser from retaining some configuration fields from the SCM, such as a “remote URL”. The fact that GitSCM does not do so currently is presumably because no one cared before.

Whether any newly added getter in GitChangeSetList or GitChangeSet (unclear which) would need to @Override some API method in core would depend on whether there is a meaningful common definition of “remote URL”. Subversion, for example, uses URLs for everything, but the “repository” is just a server base URL, whereas projects typically operate on some subdirectory; and its changelog entries are able to specify both relative and absolute paths.

@jglick
Copy link
Member

jglick commented Sep 18, 2017

Adding a new persistent field to ChangeLogSet may or may not be desirable

Ignore, it is not serializable.

@thatrevguy
Copy link
Author

Thank you for taking a look at this.

It is also unclear from JIRA what kind of report is needed—in the UI? Via Stapler exported …/api/json? Solely via Java API?

We have a plugin that generates and manages change orders in Service Now. Report is change order itself with contents including information about the change sets that triggered CICD pipeline. Reliably generating working URLs from change sets has been difficult when a pipeline performs multiple checkouts.

In any event there is no apparent downstream PR showing how this would be used, by git-plugin

I have not figured out how to build a plugin against a non upstream Jenkins core build. If there is a trivial way of doing that it'd be much appreciated to learn.

It is not even obvious to me that any core API change is needed here at all. There is nothing preventing an implementation of SCM.createChangeLogParser from retaining some configuration fields from the SCM, such as a “remote URL”. The fact that GitSCM does not do so currently is presumably because no one cared before.

This looks very much doable. I'll investigate and close this PR if I get a working PR for git-plugin.

@daniel-beck
Copy link
Member

@hathoward

I have not figured out how to build a plugin against a non upstream Jenkins core build. If there is a trivial way of doing that it'd be much appreciated to learn.

Any registered user (accounts.jenkins.io) can upload snapshot builds of anything to repo.jenkins-ci.org (mvn deploy). These will get a unique timestamp on upload for unambiguity. You can specify that version as jenkins.version property in plugin POMs.

@daniel-beck daniel-beck removed their assignment Jan 22, 2018
@batmat
Copy link
Member

batmat commented Mar 19, 2019

Hello @thatrevguy! do you plan to get back address comments here?

I am going to propose this PR for closing, and will close it if no action is taken in the next days or so.
Please feel free to comment anytime, even after it would be closed, so we reopen if you'd like to work on finishing it.

Thanks!

@batmat batmat added proposed-for-close There is no consensus about feasibility of this PR, and maintainers do not see a way forward for it stalled The PR is reasonable and might be merged, but it is no longer active. It can be taken over by other labels Mar 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-more-reviews Complex change, which would benefit from more eyes on-hold This pull request depends on another event/release, and it cannot be merged right now proposed-for-close There is no consensus about feasibility of this PR, and maintainers do not see a way forward for it stalled The PR is reasonable and might be merged, but it is no longer active. It can be taken over by other
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants