Shields: Is Wercker badge reporting the correct status?

[chris48s]

While working on #2075 I noticed that the API endpoint we're using for Wercker doesn't seem to be reporting the latest build status

e.g:
https://app.wercker.com/wercker/wercker/
https://app.wercker.com/api/v3/applications/wercker/wercker/builds

https://app.wercker.com/wercker/go-wercker-api/
https://app.wercker.com/api/v3/applications/wercker/go-wercker-api/builds

It looks to me like what we should be doing is making a call to the /runs endpoint
https://devcenter.wercker.com/development/api/endpoints/runs/

so for

https://app.wercker.com/wercker/wercker/
we should actually be calling
https://app.wercker.com/api/v3/runs?applicationId=56a9f09b4239abda60001670

and for

https://app.wercker.com/wercker/go-wercker-api/
we should actually be calling
https://app.wercker.com/api/v3/runs?applicationId=559e33c8e982fc615500b357

..but I'm slightly unclear what the difference between a build and a run is here as I'm not really familiar with the service, so I might be making the wrong assumption here.

Does anyone have any better insight on this? @pyvesb - you were the last person to refactor this, so I nominate you as the wercker expert :wink:

[PyvesB]

Indeed, the difference between a run and a build isn't very clear. As far as I can tell:

• a run corresponds to the Wercker CI executing the steps specified in a _wercker.yml_ file.
• a build corresponds to actually generating an artifact for an application.

[chris48s]

OK. Thanks for looking to that. Given our current badge endpoint is /ci, it seems like we should switch our /ci badge to report the status of the upstream /run endpoint.

We could also add another endpoint for /build, given they are different things.

Does that seem right to you? Given it links in with stuff I'm working on in #2075 anyway I'm ahppy to pick that up.

[PyvesB]

Some thoughts. Our current Wercker badges support two different URL styles, one with the project ID (/wercker/ci/projectId) and the other with the application name (/wercker/ci/applicationName, with a different regex). The latter is probably the most used as it's the one that has long been advertised on the homepage.

The issue here is that the /runs endpoint seems to require a project ID if I'm not mistaken. To migrate most users cleanly if we were to make our current badge URLs point to /runs, we would have to do two API calls, one to get the application information using its name, then use the returned project ID to get the /runs information. This is somewhat annoying as doing two API calls is slower and can bring us closer to potential rate limits. A similar badge that does two API calls is Codeclimate, and we've had problems for quite a while in #1518, partly due to us doing double the amount of queries we would normally need to.

I'm wondering whether we shouldn't separate our two URLs and advertise them independently on the homepage, with a clear description.

• /wercker/ci/projectId would point to /runs.
• /wercker/ci/applicationName would point to /builds.

The advantage here is that in both cases we would only make one API call and we keep compatibility with all our users.

[chris48s]

Yeah, we'd have to make one call to /applications to get the ID and then a second one to /runs. We do have a small handful of badges which make >1 api calls, but I do see that adding more network latency is much more likely to introduce performance issues which are difficult for us to solve because they depend on an external service.

It seems a bit odd that /ci should do 2 different things depending on how we call it, but I get that we also have backwards compatibility to think of.

Subtly different, but how about we make the primary/ 'advertised' URLs:

• /wercker/ci/projectId --> /runs
• /wercker/build/applicationName --> /builds

moving forward to make it more clear that they are different endpoints doing different things. That is probably what we would want to do if we were starting from scratch with no legacy to consider, right?

In terms of backwards-compatibility we would still have some code out there calling /wercker/ci/applicationName to think about. We could:

• make that call throw an error
• not document it on the index page, but quietly redirect /wercker/ci/applicationName to /wercker/build/applicationName in the background so that users already calling this still see the same result they currently get (I suspect this is not actually doing what users making this call _think_ it is doing though)
• just implement /wercker/ci/applicationName with 2 API calls.

:thinking:

[PyvesB]

I would be tempted to go with option 2 - quietly redirect. The code will be trivial and at the same time we ensure backwards compatibility with behaviour that is no worse than it currently is. Proper advertising on the homepage will slowly make users migrate overall.

[chris48s]

Yeah, that sounds like a plan. I'll follow this up and update #2075