search

18F / hub

DEPRECATED: Documentation hub for the 18F team
https://github.com/18F/handbook
Other
46 stars 33 forks source link

handbook.18F.gov goes to pages site #550

Closed mtorres253 closed 8 years ago

mtorres253 commented 8 years ago

So that employees of 18F can be directed to the new Handbook UI, the hanbook.18F.gov URL should point to the UI.

Acceptance criteria: hanbook.18F.gov goes to new UI

mtorres253 commented 8 years ago

@jeremiak can you let us know how much work this would be? Apparently the domain now points to a federalist site. We need it to point to the new handbook pages site

jeremiak commented 8 years ago

@mtorres253 and @andrewmaier - I'm working with the devops folks to reset my AWS password. Once I do that, this should be really easy to do.

jeremiak commented 8 years ago

I put up the handbook on Federalist with the main publishing branch as 18f-pages-internal. You can see it here: http://federalist.18f.gov.s3-website-us-east-1.amazonaws.com/site/18f/handbook/

Is it OK if the site is served from Federalist instead of 18f-pages-internal?

mtorres253 commented 8 years ago

That seems fine to me. Not sure how this affects our search work @andrewmaier @mbland

jeremiak commented 8 years ago

From the basic testing I did on the Federalist instance the search still worked. Any concerns Andrew or Mike?

On Feb 19, 2016, at 12:31 AM, Michael Torres notifications@github.com wrote:

That seems fine to me. Not sure how this affects our search work @andrewmaier @mbland

— Reply to this email directly or view it on GitHub.

mbland commented 8 years ago

There are a couple potential issues. For one, as I just recalled, I think the plan was to publish both a public as well as an internal instance of the Handbook, and Pages has support for doing both from the same branch upon a single update. The idea being, as long as the repo stays private, there could be blocks wrapped in {% if site.internal %} that would appear in the internal site and that would get stripped out of the public site.

Related to that, the Federalist site isn't authenticated. Can it require GitHub authentication for viewing? We're using bitly/oauth2_proxy with MyUSA to authenticate https://pages-internal.18f.gov/handbook/ now, set to grant access to all @gsa.gov accounts, but GitHub auth for folks in the 18F org may suffice.

The other potential issue is that, with the MVP of the federated search across the Handbook and Pages sites, we were going to load corpora from the file system and rely on a file watching mechanism to automatically pull in updates. Keeping the Handbook on Federalist means we'd have to investigate pulling corporate over HTTP. Fetching the corpora won't be a big deal, but we'll have to figure out a way to notify the lunr-server to re-fetch on update.

Of course as I wrote that I just imagined an update to jekyll_pages_api_search that can fire a webhook after a rebuild. Anyway, those are the potential issues.

mtorres253 commented 8 years ago

Seems like we should just keep it on Pages and re-point the domain. Agreed? @mbland @andrewmaier @jeremiak

jeremiak commented 8 years ago

Agreed! Just waiting on my AWS password and then will work with @mbland to make sure the DNS is pointed correctly.

andrewmaier commented 8 years ago

Yeah, @mbland I think we're sticking with private for now until we figure out the approval process to make it public.

jeremiak commented 8 years ago

@mbland FTW -> https://handbook.18f.gov/

Closing this out. Thanks for your help Mike!