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

refactor [JenkinsTests JenkinsCoverage], also run [JenkinsBuild] #3337

Merged
merged 10 commits into from
Apr 24, 2019

Conversation

calebcartwright
Copy link
Member

@calebcartwright calebcartwright commented Apr 20, 2019

Refs #2863

Summary of changes:

  • JenkinsTests badge refactored to new service arch.
    • The badge message was also changed to match our other Test badges (details inline below)
    • Added a couple helpers for test-specific badge services with the intent that they be reused for our other test badges (currently Appveyor and Azure DevOps, CircleCI and Sonar in the future, etc.)
  • JenkinsCoverage badge was refactored to leverage the new Jenkins related content added here and in refactor [JenkinsBuild] #3302.
  • The 3 Jenkins routes (Build, Coverage, and Tests) have been updated from their original shorthand/aliases to more explicit route names (with redirects to maintain backwards compatibility):
    • /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 using build, coverage, and tests 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!

@calebcartwright calebcartwright added the service-badge New or updated service badge label Apr 20, 2019
@shields-ci
Copy link

shields-ci commented Apr 20, 2019

Warnings
⚠️

📚 Remember to ensure any changes to serverSecrets in services/jenkins/jenkins-tests.service.js are reflected in the server secrets documentation

⚠️

📚 Remember to ensure any changes to serverSecrets in services/jenkins/jenkins-coverage.service.js are reflected in the server secrets documentation

Messages
📖 ✨ Thanks for your contribution to Shields, @calebcartwright!

Generated by 🚫 dangerJS against 9a415e6

@@ -84,8 +84,31 @@ function renderTestResultBadge({
return { message, color }
}

const getDocumentation = ({ route }) => `
Copy link
Member Author

@calebcartwright calebcartwright Apr 20, 2019

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.

Copy link
Member

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.

Copy link
Member Author

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

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

Copy link
Member Author

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

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.

Copy link
Member

@paulmelnikow paulmelnikow left a 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}`,
Copy link
Member

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?

Copy link
Member Author

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'),

Copy link
Member

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 thetransformPath` function above like:

function transformPath({ protocol, host, job }) {
  ...
}

Copy link
Member Author

@calebcartwright calebcartwright Apr 23, 2019

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 +

Copy link
Member Author

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?

Copy link
Member

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!

services/jenkins/jenkins-coverage-redirector.service.js Outdated Show resolved Hide resolved
// 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
Copy link
Member

Choose a reason for hiding this comment

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

🙌

services/jenkins/jenkins-tests.service.js Outdated Show resolved Hide resolved
@@ -84,8 +84,31 @@ function renderTestResultBadge({
return { message, color }
}

const getDocumentation = ({ route }) => `
Copy link
Member

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.

services/test-validators.js Outdated Show resolved Hide resolved
.required(),
optionalNonNegativeInteger,

nonNegativeInteger: optionalNonNegativeInteger.required(),
Copy link
Member

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>
@paulmelnikow paulmelnikow temporarily deployed to shields-staging-pr-3337 April 23, 2019 22:09 Inactive
@paulmelnikow paulmelnikow temporarily deployed to shields-staging-pr-3337 April 23, 2019 22:21 Inactive
@paulmelnikow paulmelnikow temporarily deployed to shields-staging-pr-3337 April 23, 2019 22:26 Inactive
@paulmelnikow paulmelnikow temporarily deployed to shields-staging-pr-3337 April 24, 2019 00:43 Inactive
paulmelnikow
paulmelnikow previously approved these changes Apr 24, 2019
category: 'build',
transformPath,
dateAdded: new Date('2019-04-20'),
}
Copy link
Member

Choose a reason for hiding this comment

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

👍

@calebcartwright
Copy link
Member Author

One last commit coming with a change to the doc

@paulmelnikow paulmelnikow temporarily deployed to shields-staging-pr-3337 April 24, 2019 00:53 Inactive
@calebcartwright calebcartwright merged commit 12191e2 into master Apr 24, 2019
@shields-deployment
Copy link

This pull request was merged to master branch. This change is now waiting for deployment, which will usually happen within a few days. Stay tuned by joining our #ops channel on Discord!

After deployment, changes are copied to gh-pages branch:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
service-badge New or updated service badge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants