Closed nathany closed 10 years ago
If we use project pages then we solve the two repos issue (#90) as well, right?
Done. I think it will show up at http://gittip.github.io/img.shields.io in the next 10 minutes, and then we can start configuring a CNAME.
Okay! Page is showing up at http://gittip.github.io/img.shields.io.
@olivierlacan We're ready for an A record for shields.io, pointing to 204.232.175.78.
Very cool. Source is at https://github.com/gittip/img.shields.io/tree/gh-pages
(We don't actually want a CNAME here because we're using the apex.)
@nathany Note that this isn't using Jekyll yet (let alone SASSSass/LESS). This is just a single static page.
oh. true, though you still need a CNAME file in gh-pages containing shields.io
. :-)
Yah. Best to let @bryanveloso chime in regarding Jekyll before setting that up. We can always use a different static site generator and .no-jekyll
if he prefers. Though sounds like everyone else :heart_eyes: Jekyll.
@nathany The problem is that this is the repo that has all the stars/forks. :-/
@nathany Actually, the problem is worse: img.shields.io is up to 6/108/6 watchers/stars/forks (16/323/32 here). We're diluting our traction, or something.
Maybe it'd be better after all to:
master
branch on shields.io for now, just have gh-pages
Good point. And all the issues.
There is the possibility of this being the Go code for the web API and img serving parts (and analytics, etc.) While the other repo is just the buckler image generation library, as per https://github.com/gittip/shields.io/issues/84#issuecomment-29123589. Though then we're back to 2 places for issues #90.
Or we find some way to merge these repos? Possibly losing history on @jbowes work, less than ideal.
Maybe GitHub support could transfer the Stargazers? Not sure if that'd be kosher.
Maybe three repos?
shields.io
- web pagesimg.shields.io
- web APIbuckler
- library + CLI(1) and (2) already exist, (3) would be new.
Maybe GitHub support could transfer the Stargazers?
Huh, never occurred to me. support@github.com would be the place to ask, I suppose. Even then, I think multiple repos makes more conceptual sense. Yes, it requires thought (and/or post facto curation) to keep issues in the right repo.
This repo has open issues for a bunch of different integrations (web hooks?) and the img.shields.io stuff has yet to be written in Go.
I'd suggest gh-pages in this repo (instead) and master becomes the API.
If we end up need the website to be more dynamic, we can always shuffle the new design from gh-pages over to master and have Go to serve it up. And multiple subdomains from a single instance (img, www/apex) are no problem if that's what we want.
A record for 204.232.175.78 added to shields.io
Killed the ALIAS to the old Heroku app.
PS: SASS is spelled Sass and is better than LESS.
Sass is my preference. :+1:
DNS change confirmed. !m @olivierlacan
So, I guess we should move gh-pages over to this repo instead, if we're gonna go ahead with multiple repos.
@nathany Am I hearing you right?
shields.io
master
- web API - http://img.shields.io/gh-pages
- web pages - http://shields.io/buckler
- library + CLI (rename from img.shields.io
)that's my thought
Okay. Should we rename the shields.io
repo (this one) to just shields
in the process?
I think it's fine as is.
Well, shields.io
was meant to be the domain name of the site in the repo, but now we have two sites in there (and it's img.shields.io
that's on master). Now it seems that the name of the repo should reflect the general name of the project, and at https://github.com/gittip/shields.io/issues/92#issuecomment-31572510 @olivierlacan asked to not use the .io
in branding.
Okay, I've done the following:
img.shields.io
to buckler
shields.io
to shields
shields/master
except for README, LICENSE, and CONTRIBUTINGshields/gh-pages
Next would be to make sure that http://shields.io/ is being served out of shields/gh-pages
.
@whit537 Thanks for doing all that. It looks like buckler/gh-pages still exists. If we remove it and shields.io still works, we should be good.
@whit537 http://shields.io is now pointing to http://badges.github.io/shields effectively loading the shields/gh-pages
branch.
Had to hack the DNS settings today since we don't have http://shields.github.io anymore due to the move the badges
organization. Instead it's the unsightly http://badges.github.io/shields which can't work with an A record or an ALIAS.
How did we have shields.github.io
in the first place? The repo was under gittip.
Anyway, glad that you got it working again.
We've got something configured wrong. http://shields.io/ is simply redirecting to http://badges.github.io/shields/. My reading of the docs is that we should ALIAS shields.io
to badges.github.io
, and then the CNAME file in the shields/gh-pages branch should take over there (I think?).
@olivierlacan It looks from the screenshot like you're using DNSimple. They do provide the ALIAS
record type to provide CNAME functionality using the apex domain, and that's what we should use.
DNSimple also allows sharing the domain configuration with others, if you want to let @whit537 fiddle with it.
If the badges.github.io
repo is somehow impacting things, we probably can rename it? (which probably does mean taking that site down) @Mikulas
We could keep the existing badges.github.io page up as a subpage or subdomain of shields.io until we figure out our transition plan (#101).
Per https://github.com/badges/shields/issues/96#issuecomment-32003530, can we give @seanlinsley the permissions he needs to work on this ticket?
@olivierlacan Status? :-)
I've asked @olivierlacan for access to DNS.
DNS reticketed as #115.
I believe this is fixed. We are using GitHub pages.
Just as a start, before doing a full-on redesign.
bundle exec sass --watch _sass/all.sass:assets/all.css --load-path _sass/
(Procfile)