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

Merge job started messages based on aggregation interval #313

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Jimilian
Copy link
Contributor

The main goal of this PR is to reduce number of notification user receives from Gerrit Trigger Plugin.
It allows users to specify "aggregation interval", so all jobs that were started in this interval would merge buildStarted message in one.
I.e. you do aggregation interval 10 seconds, after that 3 builds are started:

1. build1 at 00:00
2. build2 at 00:09
3. build3 at 00:11

PR will merge build1 and build2, so, plugin will send

Build started:
build1_url
build2_url

After that build3 will be sent separately:

Build started
build3_url

We already are using this feature in production (since previous week), looks good.

Copy link
Member

@rsandell rsandell left a comment

Choose a reason for hiding this comment

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

Halfway through.

@@ -70,7 +70,7 @@ public String getBuildStartedMessage(Run build) {
*/
@Deprecated
public String getBuildStartedMessage(AbstractBuild build) {
if (thisOverrides("getBuildStartedMessage", Run.class)) {
if (thisOverrides("getBuildsStartedMessage", Run.class)) {
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 unrelated and wrong.

Or maybe not when reading the rest of the PR, but it does still look wrong, since the check is if a specific method is overridden and in that case that method should be called, but the method checked for is not the method getting called.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

minVerified,
Notify.ALL.name());

parameters.put("BUILDURL", "");
Copy link
Member

Choose a reason for hiding this comment

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

I guess it would have been better if we could change the command templates and separate the message part with the actual command part. And then in case of a compound message like this the message part would be just two messages correctly expanded with BUILDURL and all and added to the one command.
This seems a bit hacky to me as it omits certain variables in case an admin has changed the message format.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I did it, because it was already like that implemented for Completed message (it just ignored BUILDURL) completely :). I don't want to touch template part in my PR, but I can add more details in help section.

if (entry == null) {
continue;
}
runs.add(entry.getBuild());
Copy link
Member

Choose a reason for hiding this comment

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

getBuild() can also be null if jobs have been triggered but not yet started.
Even though you take care of potential null entries below it is safest if we can omit them all together in the source in case some other caller isn't that foreseeing.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

* @param listener listener
* @param event event
* @param stats stats
* @return the message for the build started command.
*/
public String getBuildStartedMessage(Run build, TaskListener listener, ChangeBasedEvent event,
Copy link
Member

Choose a reason for hiding this comment

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

I'm still nervous of removing signatures like this, even though it should be safe in this context as only careless plugina uthors would rely on this code.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If you want, I can restore this one and mark like @Depracated

@neonman63
Copy link

Hello, we need same behavior not only for "started message", but with entire build triggers, because with topic upload to the gerrit had triggers many jobs with same changesets. May be I can open a feature request in JIRA?

@Jimilian
Copy link
Contributor Author

@neonman63, what do you mean by "entire build triggers"? In our case we received two types of messages:

  • job started (once per job)
  • final aggregated result

@neonman63
Copy link

We push code with repo tool in 4 project with topic and this triggers 4 jobs. In each job we use python-script, which get code in each project by topic (rest api requests to gerrit for getting depended changesets). Finally, it sets 4 +1 votes (or -1) in each changesets with same topic and with same build results.

@Jimilian
Copy link
Contributor Author

@rsandell can we follow up on it? Our devs are happy to have less messages in Gerrit.

@Jimilian Jimilian force-pushed the merge_job_started_messages branch 2 times, most recently from 1edbeab to 5a07dfe Compare October 26, 2017 08:44
@rsandell
Copy link
Member

@Jimilian yea, the PR is just so big I have a hard time finding gaps in my day big enough to review it :'(

@Jimilian
Copy link
Contributor Author

@neonman63 btw, there is a new feature "abort same topic".

@panicking
Copy link
Contributor

@Jimilian Abort topic insist on the same git repo right? I mean if you have multiple patches on different repo with the same topic multiple job are anyway triggered or it's a way to define one job?

@Jimilian
Copy link
Contributor Author

@panicking current implementation aborts all executions regardless project, because it assumes that topic used at moment of start is out-dated already.
In my company we are using Gerrit Trigger Plugin with "native" topic support that triggers all jobs for all changes with respected context. I.e.

  • topic contains changes in projectA and projectB.
  • there is three jobs: jobA (configured to be triggered on change in projectA), jobA (projectB) and jobAB (both projects)
  • user pushes first change (in projectA): only jobA and jobAB are triggered
  • user pushes second change (in projectB): both executions are aborted, three jobs are triggered (jobA, jobAB, jobB)
  • once all jobs are completed user receives feedback from jobA/jobAB for projectA and from jobB/jobAB for projectB

Abort same topic is only one part of this big picture.

@panicking
Copy link
Contributor

@Jimilian So we can't use this plugin as it is to run one job for same topic but you need to have a modified version of it

If multiple jobs are configured to be triggered by GTP it can be too
annoyning to get feedback/notification from each of them.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants