Deployment

[Bartvds]

@sebastian-lenz Since you're now the man for the implementation of the site, did you catch how this thing is deployed?

I think the README covers most of it: but basically Travis CI builds whenever anything lands in the source branch, and then uses grunt-gh-pages (with @dt-bot 's credentials) to git-push the static content to the master branch.

When Travis rebuild it runs docpad in production mode (with minify-ing and other stuff like that) so you don't have to manually do that.

Travis runs grunt deploy and pushes using @dt-bot's credentials. You can check locally what it builds using grunt build. You can also publish manually from local with grunt publish but they it'll ask your own github credentials.

@dt-bot's token is encrypted in .travis.yml and so only can be decrypted on Travis and only in a push webhook, but not a PR. This is a security thing from Travis so random people can't add some code to dump the decrypted token to the Travis log (well, they can but it'll only work if we'd actually merge their hack so keep an eye on code changes).

In some earlier tickets (like #26) I spoke about rebuilding on our own server instead of Travis, but that's only needed if we want to rebuild from a webhook in the DT main repo (like if we'd generate static pages for each def). I guess for now the .json based search is fine and we'll can go for the other option at later point (let's not block the updated site on that).

[sebastian-lenz]

Thanks for detailing the deployment, I saw the tasks in the grunt file and just had a basic idea of the workflow. Wanted to ask you where the security issues arrise, but after some googeling I discovered that you've already written an in-depth guide. Nice reading!

So the whole deployment seems perfectly setup to me, you've covered security and usability issues, there is absolutely no reason to change anything. Even if we build an automated package listing, we could run it through a separated process I guess.

Yes, I would also prefer release an update to the site before everything else like the blog or documentation discussions are wrapped up. Just let's get moving and simply change things when they are ready. You wanted to change/update the JSON index file, how are your plans with that one? Should we start with the current one or directly switch to the new one? Currently I plan to start building the site as soon as I get some PSDs from Rodrigues.

Ah, one thing left. Currently I'm pushing my changes into a fork on my account so the rest of the team cannot change anything. Should I move the new site to another repro or to a branch or should I stay with the fork and merge it when it's finished?

[Bartvds]

Hah, great you found my guide: when I finally figured out how to do this I was so pleased with it I had to document it 😄 (it is magic stuff).

Note the reason we use @dt-bot is because the push back to Github needs an Oath token: I could use my own token but Github tokens cannot be limited to selected repos so if someone would dump mine to the Travis log they can pwn all my own (private) repos. My boss and clients' legal counsel would have my head on a spike if I'd expose my own personal token (and thus their business) to people I met on the internet (eg: DT org members).

But @dt-bot only has access to some DT repos so potential damage of extracting the token on Travis is limited to DT org members who'd have commit access anyway. Note how in the Gruntfile there is a setting on gh-pages that sets the task that uses the token to 'silent'. This is very important because otherwise the token leaks to the logs (via the url in the git commands that are logged if not-silent).

If for some reason the token accidentally does leak then immediately notify me so I can revoke the token and make it harmless (maybe I'll send @dt-bot's login to some more members so they can do that too 24/7).

I agree we should just release an update soon and add new features later. It'd be great to have the new look and the improved search online as soon as possible, the rest can wait until after that.

For the new .json: I want to rig it with the webhook and stuff so it auto-updates. I'm a bit busy now I got a regular day job again so let's not block on that either: it is essentially the same kind of data so we can change that later too (this is a priority on my list though so should be ready soonish).

So I think you can just move ahead at your discretion (you got the access now).

Could indeed be good to move development to a branch of this repo. Only the source and master are magic so feel free to add branches as you need them. Then at some point merge your development branch to source and it'll go live.

I think merging to source by internal PR is nice as the other collabs (& watchers) will then get a notification (also good if you want feedback). On the other hand when doing small fixes a PR note is not really needed and a direct push to source will do fine, so choose per case.

[sebastian-lenz]

Dam, so I cannot access your private repros 😉. I think I mentioned it before, this is a really cool way to use the services available here. Being aware of the pitfalls of this technique, I will have an eye on the critical parts and inform you when noticing anything suspicious.

The current JSON file is cool and we can definitely go with that one, just wanted to ask for the status.

When the bot has no problems with commits to another branch in the repro I will start a new relaunch branch so everyone in the team has access to it.

[Bartvds]

Cool. Branch safety should be good, Travis only deploys source: https://github.com/DefinitelyTyped/definitelytyped.github.io/blob/source/.travis.yml#L8-L10