proof of concept rendering versioned guides by commit ref

[collin]

@wagenet

Ripping through the git repo with the "grit" gem to get guides and the guides.yml for individual commit references. Could be tags or branches.

I seem to have broken the rendering for the sidebar and the markdown a little bit. I hacked something to render markdown through tilt in an erb template.

[collin]

Doing a little recursion here to rip through the guides markdown files.

[collin]

To try this out make sure to visit http://localhost:4567/master/guides

There would need to be some polishing up of links and some way to set a default guides version or something.

[joefiorini]

@wagenet Is this the kind of versioning you were thinking of? Or should we do something similar to Rails guides where we deploy edge and release docs to separate subdomains?

[joefiorini]

I'm gathering some more details on how Rails handles this for docrails; I'm currently putting it together into a proposal for Ember and will have something soon.

[wagenet]

I'm hoping to review both this and @joefiorini's proposal soon.

[tomdale]

Would love to see this feature land.

[wagenet]

I would love to as well. Unfortunately, I haven't had time to review yet.

-Peter

On Jan 19, 2013, at 2:25 PM, Tom Dale notifications@github.com wrote:

Would love to see this feature land.

—
Reply to this email directly or view it on
GitHubhttps://github.com//pull/237#issuecomment-12462325.

[joefiorini]

Since putting it on Twitter doesn't make it very discoverable, my proposal is at https://gist.github.com/8a3f3976b0bca4081251.

[joefiorini]

@wagenet any opportunity to review yet?

[stefanpenner]

@collin this is a great idea! Can we get this working on master?

[collin]

I wasn't able to get the "def current?" helpers to work, but this time I got the markdown rendering properly.

Could probably re-use this concept for api versioning as well.

[collin]

@stefanpenner Are you familiar with the code that adds classes to the current pages? The 'active' style for the main 'guides' link is also lost with this.

Could also use some styling on the navigation.

[stefanpenner]

@collin stefanpenner@9a72cad <-- quick adjustment to 'fix' the active styles.

This is a good start, we will also need to do similar for the guides. We should coordinate!

[joefiorini]

@wagenet have you had a chance to review my proposal for this? https://gist.github.com/8a3f3976b0bca4081251.

[stefanpenner]

@joefiorini we can likely add this to the end of every successful travis run.

[joefiorini]

@stefanpenner that's a great idea! I haven't used travis much, but I'm guessing it would do an HTTP push to the build server?

[stefanpenner]

@joefiorini travis is essentially the build server. Anyways, once the tests run, all the artifact needed for all variations of master are available. We would simply need to push them to s3 or something.

[joefiorini]

I've hosted a few sites on S3 and love it. I would be happy to setup this site on there as well, if that's the route we want to go.
—
Sent from Mailbox for iPhone

On Sat, Mar 16, 2013 at 5:52 PM, Stefan Penner notifications@github.com
wrote:

@joefiorini travis is essentially the build server. Anyways, once the tests run, all the artifact needed for all variations of master are available. We would simply need to push them to s3 or something.

Reply to this email directly or view it on GitHub:
#237 (comment)

[mharris717]

Question about producing the website as of a past commit ref.

The website is generated from the website and ember.js repos. Specifying a ref for one doesn't specify where you want the other.

Say I want to generate the website as of ref A in the website repo.
Would i set the ember.js repo to "whatever ref was current at the time A was created"?

[mharris717]

I'm willing to help get this moved toward completion.

It seems like there are two ways to do this:

1. Generate the website for a ref/time on the fly, likely by introspecting the repo with git.
2. Pre-Generate specified refs by checking out that ref, building the site, and pushing to S3.

Building and pushing the "edge site" on each commit (likely with a travis or github hook) works with both options.

I would vote for #2. Seems simpler and faster.

I'm happy to setup a little site on heroku (or a box/vps/etc anyone wants to donate) that could accept travis' build hook, generate the docs and push to S3. If it were up to me, I'd put the code in its own repo and throw that up on heroku, but I'm happy to do whatever.

[stefanpenner]

@mharris717 ping me on gtalk or something (stefan.penner@gmail.com) we can have a nice high bandwidth chat.

[joefiorini]

@stefanpenner @mharris717 I'm happy to help get this setup as well. Can I help you guys to coordinate this?

[stefanpenner]

@joefiorini awesome, feel free to ping me.

[mharris717]

@joefiorini Definitely. Seems like this should be doable.

[mharris717]

Added #481

From that PR:

This PR does several things:

Incorporates @joefiorini's PR to add S3 uploads of built docs.
Adds ability to build docs for previous versions and upload to S3
Adds .travis.yml file for travis builds
Pushes latest docs to an edge S3 bucket on successful travis build.
Adds page on emberjs.com with links to old docs.

[stefanpenner]

closing in favour of the active: #481