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

The Great [Wercker] Rewrite #1920

Merged
merged 5 commits into from
Aug 16, 2018
Merged

The Great [Wercker] Rewrite #1920

merged 5 commits into from
Aug 16, 2018

Conversation

PyvesB
Copy link
Member

@PyvesB PyvesB commented Aug 14, 2018

Users seem to have been dissatisfied with our Wercker badge offering for quite some time (see #825, #604, #980 and #455). This pull request attempts to improve things:

  • we now have a proper test suite.
  • the implementation has been rewritten using the new JSON service base.
  • support has been added to optionally target specific branches.
  • badge error messages have been clarified.
  • the example on the homepage has been fixed, as it has been invalid for a long time: .

Looking forward to feedback! 👍

@PyvesB PyvesB added the service-badge New or updated service badge label Aug 14, 2018
@PyvesB PyvesB changed the title [Wercker] The Great Wercker Rewrite The Great [Wercker] Rewrite Aug 14, 2018
@shields-ci
Copy link

Messages
📖

✨ Thanks for your contribution to Shields, @PyvesB!

📖

Thanks for contributing to our documentation. We ❤️ our documentarians!

Generated by 🚫 dangerJS

chris48s
chris48s previously approved these changes Aug 15, 2018
Copy link
Member

@chris48s chris48s left a comment

Choose a reason for hiding this comment

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

Nice - looks good. Left one minor comment.


t.create('CI connection error)')
.get('/ci/wercker/go-wercker-ap.json')
.networkOff()
Copy link
Member

Choose a reason for hiding this comment

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

Now that this is check handled in the base class, we don't need to explicitly test it for every service any more unless there is some special handling of this case.

It is still useful for the services defined in server.js where we're doing the checks manually, but as we port stuff over to the new layout we can dispense with this.

Copy link
Member Author

Choose a reason for hiding this comment

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

Fair point - removed that test.

chris48s
chris48s previously approved these changes Aug 15, 2018
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.

Thanks so much for taking this on!

: `https://app.wercker.com/getbuilds/${projectId}?limit=1`
if (branch) {
url += `&branch=${branch}`
}
Copy link
Member

Choose a reason for hiding this comment

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

This would be better handled, IMO, by including options: { query: { branch} } in the call to requestJson(), which I believe will do the right thing. Plus it will URL-encode it, if necessary, and avoids any possibility of a vulnerability where extra parameters could be injected into our request via branch. Does that make sense?

Copy link
Member Author

Choose a reason for hiding this comment

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

Good point. After some trial and error, I believe qs is actually the right field to set here.

static render({ status, result }) {
if (status === 'finished') {
if (result === 'passed') {
return { message: 'passing', color: 'brightgreen' }
Copy link
Member

Choose a reason for hiding this comment

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

If we are translating passed to passing, why does the build status regex need to be updated?

Copy link
Member Author

Choose a reason for hiding this comment

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

Hmmm... I must have added this part way through rewriting the service, didn't think about removing it later.

async handle({ applicationName, projectId, branch }) {
const json = await this.fetch({ applicationName, projectId, branch })
const status = json[0].status
const result = json[0].result
Copy link
Member

Choose a reason for hiding this comment

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

You can assign these using destructuring:

const { status, result } = json[0]


t.create('CI private application')
.get('/ci/wercker/blueprint.json')
.expectJSON({ name: 'build', value: 'private application not supported' })
Copy link
Member

Choose a reason for hiding this comment

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

😍

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 happy about how this tied into my previous piece of work, #1888, which made things really easy here. 😄

@paulmelnikow paulmelnikow added the bug Bugs in badges and the frontend label Aug 16, 2018
@PyvesB
Copy link
Member Author

PyvesB commented Aug 16, 2018

Thanks for reviewing @chris48s and @paulmelnikow!

@PyvesB PyvesB merged commit 886cde7 into badges:master Aug 16, 2018
@shields-deployment
Copy link

This pull request was merged to master branch. Now this change is waiting for deployment.
Deploys usually happen every few weeks. After deployment changes are copied to gh-pages branch.

This badge displays deployment status:

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

Successfully merging this pull request may close these issues.

4 participants