-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
refactor [JenkinsTests JenkinsCoverage], also run [JenkinsBuild] #3337
Conversation
|
services/test-results.js
Outdated
@@ -84,8 +84,31 @@ function renderTestResultBadge({ | |||
return { message, color } | |||
} | |||
|
|||
const getDocumentation = ({ route }) => ` |
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 is one of those things that I saw duplicated in appveyor-tests.service.js and azure-devops-tests.service.js.
Instead of replicating it again for JenkinsTests, I figured it would be better to put it here in one place and consume it from the other services (if there's no opposition to this, I will open a future PR to update Appveyor and Azure DevOps test services to leverage this). We've also got some additional test badges that have been requested (for example CircleCI and Sonar) that can reuse this as well.
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.
Sounds good! I'm not sure it's essential to put the route in there, and leaving it out would simplify this, though I don't object.
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.
Yeah I think having the full route in the doc was more helpful back before the window we have today that will auto populate the the query params for users.
I can remove that section (and change this to a simple static prop) if we're good with no longer including that
skippedLabel, | ||
isCompact, | ||
}) { | ||
return renderTestResultBadge({ |
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 is a clear change to our badge message for Jenkins Tests (before the refactor the message was: ${passed} / ${total}
.
However, I believe this is worthwhile as reusing the renderTestResultBadge
helper here provides a lot of new formatting capabilities and brings the Jenkins Test badge message format in alignment with our other test badges (Appveyor and Azure DevOps)
// The below page includes links to various publicly accessible Jenkins instances | ||
// although many of the links are dead, it is is still a helpful resource for finding | ||
// target Jenkins instances/jobs to use for testing. | ||
// https://wiki.jenkins.io/pages/viewpage.action?pageId=58001258 | ||
|
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've updated the tests to use different Jenkins instances that seem to be much more performant and stable than the Apache instance. That gives us good test targets to validate both jacoco and cobertura coverage formats, so I've removed several of the mock tests accordingly (I believe we were mocking due to the lack of consistently available live jobs)
) | ||
.has(Joi.object({ name: 'Lines' })) | ||
.min(1) | ||
.required(), |
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.
Jenkins will return an HTTP 404 if a job is requested that did not publish code coverage in the cobertura format (which is why on a 404 we use the error message job or coverage not found
).
If the target job has cobertura coverage then the elements array will include an object with a Lines
field, which is what we need.
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.
Nice work on this! Appreciate all the refactoring you've done; it makes this whole situation much nicer.
Happy to review the additional refactors in a follow-on.
pattern: ':protocol(http|https)/:host+/:job+', | ||
}, | ||
transformPath: ({ protocol, host, job }) => | ||
`/jenkins/build/${protocol}/${host}/${job}`, |
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's not immediately obvious these are the same. Maybe you could define the transformPath
function above to help clarify?
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'm not following, could you rephrase?
The legacy route accepted a base of jenkins|jenkins-ci
and for the metric it accepted s
as a shorthand for build status. Are you suggesting combining that into a single redirector, perhaps like the below, or something else entirely?
redirector({
category: 'build',
route: {
base: '',
pattern: ':alias(jenkins|jenkins-ci)/s/:protocol(http|https)/:host+/:job+',
},
transformPath: ({ protocol, host, job }) =>
`/jenkins/build/${protocol}/${host}/${job}`,
dateAdded: new Date('2019-04-20'),
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.
Ah, sorry!
These two redirects are basically doing the same thing; one is for /jenkins/sand the other for
/jenkins-ci/s. This would be clearer if the
transformPathfunctions, which are identical, weren't duplicated. Could you define the
transformPath` function above like:
function transformPath({ protocol, host, job }) {
...
}
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.
oh also host
should be .../:host/...
without the +
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.
Got it, thanks for the clarification. Do you think it would be more clear with two redirector services (leveraging a single transform function), or combining them into a single redirector?
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 two would be more performant if we do #3328, so thinking ahead, I'd be inclined to stick with that!
// The below page includes links to various publicly accessible Jenkins instances | ||
// although many of the links are dead, it is is still a helpful resource for finding | ||
// target Jenkins instances/jobs to use for testing. | ||
// https://wiki.jenkins.io/pages/viewpage.action?pageId=58001258 |
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.
🙌
services/test-results.js
Outdated
@@ -84,8 +84,31 @@ function renderTestResultBadge({ | |||
return { message, color } | |||
} | |||
|
|||
const getDocumentation = ({ route }) => ` |
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.
Sounds good! I'm not sure it's essential to put the route in there, and leaving it out would simplify this, though I don't object.
.required(), | ||
optionalNonNegativeInteger, | ||
|
||
nonNegativeInteger: optionalNonNegativeInteger.required(), |
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.
Bet there are a lot of places where we can use this!
Co-Authored-By: calebcartwright <calebcartwright@users.noreply.github.com>
category: 'build', | ||
transformPath, | ||
dateAdded: new Date('2019-04-20'), | ||
} |
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.
👍
One last commit coming with a change to the doc |
Refs #2863
Summary of changes:
/jenkins/s
-->/jenkins/build
/jenkins/c
-->/jenkins/coverage
/jenkins/t
-->/jenkins/tests
I know there's still ongoing discussion around what our url conventions are for
build
, but usingbuild
,coverage
, andtests
for Jenkins aligns the url's with the other service (Azure DevOps) we provide multiple metric badges for.Using
build
also seems to be relatively common in our badge url's for other services where the service name doesn't automatically default to build status (like we do for TravisCI). Definitely open to feedback/suggestions though!