-
Notifications
You must be signed in to change notification settings - Fork 0
AGDIGGER-60 - allow to stream artifacts #1
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
AGDIGGER-60 - allow to stream artifacts #1
Conversation
…nkins-job AGDIGGER-59 trigger jenkins job
<dependency> | ||
<groupId>org.mockito</groupId> | ||
<artifactId>mockito-core</artifactId> | ||
<version>${mockito-core.version}</version> |
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.
Good point: let's use properties for versions... I will do this for the rest of the deps
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.
@wtrocki as we talked. maybe you can do it for the rest of the deps too.
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.
IMO it's a bit redundant nevertheless since they are used only in one place each
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.
but it's usually much nicer to have those covered in a properties section
|
||
import static org.junit.Assert.assertNotNull; | ||
import static org.junit.Assert.assertNull; | ||
import static org.mockito.BDDMockito.given; |
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.
@wtrocki I had the old TDD style used in other tests. I think we should use one approach.
Unless you have strong opinions about BDD, I will convert given
to when
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.
Ok, I won't do it. you do it :)
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.
+1 on when
, same as in UPS
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.
Sorry. We did not had any tests when I started working on that. Fully agree.
|
||
} | ||
} catch (Exception e) { | ||
LOG.error("Problem when fetching artifacts for {0} {1} {2}", jobName, buildNumber, artifactName, e); |
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 think it might be better to throw an exception instead of just returning null in case of an error.
Any objections?
given(job.getBuildByNumber(anyInt())).willReturn(build); | ||
|
||
InputStream artifact = artifactsService.fetchArtifact("artifact", 1,"test"); | ||
assertNull(artifact); |
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.
assertj is much nicer
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.
@wtrocki I've already introduced it. (this PR needs a rebase)
@wtrocki maybe add a how to in README file? |
…nkins-job-2 AGDIGGER-59 trigger jenkins job - 2
<dependency> | ||
<groupId>org.mockito</groupId> | ||
<artifactId>mockito-core</artifactId> | ||
<version>${mockito-core.version}</version> |
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.
IMO it's a bit redundant nevertheless since they are used only in one place each
*/ | ||
public InputStream fetchArtifact(String jobName, int buildNumber, String artifactName) { | ||
ArtifactsService artifactsService = new ArtifactsService(jenkins); | ||
return artifactsService.fetchArtifact(jobName,buildNumber,artifactName); |
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.
There are some spaces after commas missing here
*/ | ||
public class ArtifactsService { | ||
|
||
private JenkinsServer jenkins; |
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.
Should this be final
?
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.
good call, I also miss a bit of final
usage on various places here
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 cannot be final now after rebase and api change.
try { | ||
JobWithDetails job = jenkins.getJob(jobName); | ||
Build build = job.getBuildByNumber(buildNumber); | ||
if (build instanceof BuildWithDetails) { |
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.
IMO this function body is a bit confusing. I would add an else block instead of having multiple return statements. When return statements are close it's easy to understand it but here there are a try-catch
block, an if-else
block and two return
all mixed up.
A quick solution I would made is to inverse the predicate:
if (!(build instanceof BuildWithDetails)) {
return ... ;
// or better -> throw new WhatEverException();
}
} | ||
|
||
} | ||
} catch (Exception e) { |
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.
Couldn't this be a bit more specific? So we can identify the kind of Exception we are actually expecting.
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.
+1000 fine grain is much better - Exception is almost all, execpt for Error :)
|
||
public class ArtifactsServiceTests { | ||
private String jobLocation = "http://localhost/job/artifact/"; | ||
private JenkinsServer server = mock(JenkinsServer.class); |
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 am more fond of @mock annotation
import static org.mockito.Mockito.verify; | ||
|
||
public class ArtifactsServiceTests { | ||
private String jobLocation = "http://localhost/job/artifact/"; |
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 would avoid field initialisation, instead I find more convenient doing it inside @before method
private JenkinsServer server = mock(JenkinsServer.class); | ||
|
||
@Test | ||
public void testGetNoArtifacts() throws Exception { |
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.
IMHO tests naming should be more explicit, it's hard to understand what this test is about for example
@wtrocki FYI |
Motivation
Allow to stream jenkins artifacts by name.
Review @aliok