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.

[sysarcher]

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.