Crates.io: Travis CI badges may come from `travis-ci.com`

[kennytm]

Currently Travis CI badges are hard-coded to use travis-ci.org. However, Travis recently announced that new open source projects will be stored on travis-ci.com and the old ones will soon be migrated.

There should be some way to choose the .com site for the badge.

[sgrif]

It sounds like we'll probably just need to switch 100% to .com at some point. I'd like to get details on how specifically the migration affects status badges which isn't detailed in that blog post.

[kinggoesgaming]

How about having a two step process for now:

check if it exists on travis-ci.com and if it fails for any reason fallback to travis-ci.org

When the migration is complete from travis simply drop the fallback code

[Dragonrun1]

I was trying to figure out why my new crate was showing unknown status until I finally looked closely and realized the URL was wrong. I like @kinggoesgaming idea as it is the most forward-looking solution IMHO.

Just my guess on when they switch the URL on projects is when you switch from the old style GitHub hooks to the new Apps interface. I'm sure at some point they'll force everyone to make the switch but crates should have already been updated long before then.

[shrmrf]

Now might be the time to update the URL :)

[sondr3]

Now it is really starting to become time to fix this, all new projects created from the blog post a month ago will default to using travis.com over travis.org, meaning the default behavior is wrong. I'd love to fix this myself and get my hands dirty, but I don't know where to start. @steveklabnik (sorry for the tag)

[jtgeibel]

@sondr3 I can point you in a few directions and mention a few areas that may be a bit tricky:

• First, I have no idea if cargo includes its own checks on the badge attributes. If so, then similar changes will be needed there as well.
• We store badge attributes in a jsonb column in the database, so this shouldn't require schema changes.
• Badge attributes are validated when the crate is published. Basically, we make sure the badge metadata can deserialize into our Badge enum. We can add another field there that is an Option<TravisDomain> where TravisDomain is an enum allowing com or org. It needs to be optional so that existing TOML files aren't rejected for not including this attribute.
• I'm less familiar with the frontend, but I think you'll need to update the component and its template. For now, I think the default needs to be org to make sure existing badges without that field will not be changed accidentally. Once all projects are migrated on travis, we could consider changing the default to com and removing the support for customizing the domain.
• Update the cargo docs to demonstrate and explain the new option.

[sondr3]

Doesn't sound too hard (famous last words), I'll take a look over the weekend. Thanks for the pointers @jtgeibel 😄

[jtgeibel]

Sure thing! Let me know if you have any questions along the way.

[pietroalbini]

Basically the situation is that the Travis migration tool isn't ready (and judging by their progress and the acquisition I think it's not going to be ready for a while) so they postponed the switch from .org and .com for existing repos to an unknown (to us) date. New repositories are added on .com though today, so we'll need to handle badges.

There are two ways we could handle this (that I can think of):

• Make a call to the Travis API in the backend to check if the repo is on .org or .com. This is seamless to the crate author, but it will add some delay to the pages. That could be handled by caching the result for like days, but it will still affect less visited crates a lot.
• Have the crate owners explicitly change the badge declaration to specify they're on .com. That doesn't add overhead to our backend, but it's churn for the crate authors. We will also need to find a way to make this compatible to when everyone will be migrated to .com.

[djmcgill]

I recently encountered this issue when using cargo-readme which also generates a badge url from the manifest attribute. To be as simple as possible I just went with the explicit approach:
https://github.com/livioribeiro/cargo-readme/pull/29

[badges]
travis-ci = { repository = "cargo-readme/test", tld = "com" }

n.b. only "com" and "org" are accepted in that PR. The key is optional and defaults to "org" so it's entirely backwards compatible.

When (if) travis do make the switch we can just change the default to be com.

[pietroalbini]

We talked with our contacts at Travis CI, and they're looking into providing an unified badges URL regardless of the tld. We'll have more information about this in the coming weeks, so I'd hold on adding a new attribute to the manifest for now.

[pietroalbini]

Travis CI doesn't have an exact timeline yet but they'll let us know in the next week.

[pietroalbini]

There is another update from Travis CI!

They implemented badges redirect on their end, so a travis-ci.org badge will redirect to .com if the repo has been migrated! There are a few small bugs on their implementation (mostly some of the repos don't properly redirect yet), but I already reported those issues and they'll fix them on their end.

Thanks to that the badges themselves are already fixed, but the links are still pointing to .org even if the repo has been migrated. What we can do to fix the issue on our end is to add a bit of JavaScript that replaces the link to use the same tld as the image once it's loaded. Anyone up to implement that?

[kennytm]

if the repo has been migrated!

but what about new repos?

[pietroalbini]

@kennytm that's the bug I was talking about ;)

As far as I can see it's supposed to redirect to .com even if the repository doesn't exist on .org, so new repos should be handled by that. The bug is that the redirect doesn't happen if the repos are on .org's database but marked as inactive.

[kzys]

Can we remove P-high from the issue now?

[glandium]

Apparently something changed on travis in the past 24 hours. I uploaded a new crate yesterday, with its CI on travis-ci.com. The badge showed "passed" properly then. But it shows "unknown" today.
However, a cursory check seems to indicate that api.travis-ci.com now serves badges for both .com and .org-hosted projects. So it would seem it'd be time for crates.io to switch to api.travis-ci.com for everything.

[kzys]

Interesting. Yes. Both https://travis-ci.com/rust-lang/crates.io/ and https://travis-ci.org/rust-lang/crates.io/ use https://api.travis-ci.com/rust-lang/crates.io.svg?branch=master.

The link issue is still annoying. https://travis-ci.com/rust-lang/crates.io/ works but https://travis-ci.org/rust-lang/crates.io/ shows "This repository was migrated and is now building on travis-ci.com" and doesn't automatically redirect to the com equivalent. So always pointing .org technically works, but asks users additional 1-click.

Always pointing .com simply doesn't work. https://travis-ci.org/kzys/2014/ is my old Travis-integrated GitHub repos, but https://travis-ci.com/kzys/2014/ shows "We couldn't find the repository".

What @pietroalbini suggested

What we can do to fix the issue on our end is to add a bit of JavaScript that replaces the link to use the same tld as the image once it's loaded. Anyone up to implement that?

would not work since api.travis-ci.com doesn't redirect to .org.

So, we may need the tld attribute, as @djmcgill suggested.

[glandium]

Weird, my own github repos still on travis-ci.org have working badges on travis-ci.com. Is it because I also have active repos on travis-ci.com, but you don't?

[kzys]

Might be. I have nothing on travis-ci.com.

[Turbo87]

we've today decided to remove the badges from the UI and only keep those that are in the README of the project, so this issue will probably resolve itself that way. more details are available in https://github.com/rust-lang/crates.io/issues/2436