Git hook support
Opened this issue · 5 comments
What I want is a simple way to publish changes to my Haiku9 Web site via a git hook.
Haiku9 is great.
Publishing is easy.
But it still requires me to push to a branch and then publish.
I can script this, but I still have to write the script.
But if we had an API for publishing,
we could set up a git hook so that pushing
would automatically publish to a corresponding environment.
What's more, I think we could use Mango to do this.
We'd simply pull the corresponding branch,
build the site, and publish it to the appropriate environment.
Failing that, we could provide this as a service
and integrate the CLI into H9's, ex: h9 hook or something.
Damn it, why doesn't GitHub respect semantic line-breaks?
I suppose h9 hook could just set up a local hook.
We could do this for Mango, too.
If it is going to be a tool that we use on h9 and on panda-sky, maybe we should make it a self-sustained tool? Something like https://github.com/brigade/overcommit but for JS projects?
lance dan: david I'm waiting for h9 to publish to production "Waiting for CloudFront distribution to deploy. This may take several minutes." This makes me wonder how easy it would be to put almost all of the publish stuff into a one-time-lambda so that when you run h9 publish all h9 publish does is create everything needed to create a one-time-lambda which runs all of the publish stuff and then removes itself.
david I don't understand the objection to running h9 publish on your computer. I could create a lambda with a "caller pays" setup, but writing it could be gross from a permissions standpoint.
david It should be noted that the DNS change detection is a bit buggy in H9. That's going to be improved in the short-term as Route53 and CloudFront operations get moved into CloudFormation templates, like how PandaSky works.
lance david: My "objection" to having h9 publish locally is experimental and trivial. It's definitely not critical. It's partially preference. 1) In general I dislike foreground processes which take a long time. There are of course exceptions. Something feels wrong about deploying from my laptop in the foreground and having a foreground process wait 15+ mintues while CF is updated and invalidated. It just feels wrong. That doesn't mean it's critical to change it. We're doing it simply and it's working. Additionally, what I prefer for me isn't necessarily easy or good for our product and everyone. 2) I like the experimental idea I described but I haven't thought through the implementation, complexity, and product implications.
lance david: What is "caller pays" ?
david Oh, requester pays is only for S3 buckets.
david I somehow thought that applies to Lambdas, but my research came back negative
david People are clamoring for it, apparently, though, haha
lance david: Interesting.
http://docs.aws.amazon.com/AmazonDevPay/latest/DevPayDeveloperGuide/S3RequesterPays.html
I didn't know this was a thing.
lance david: I wasn't thinking of a requester pays setup for the h9 publish lambda thing. I wasn't really thinking about h9 as a product / project that others are using at the moment that I thought of this. What I was thinking amounted to wondering if we could do it on our own AWS account and lamdas and, to extend that to the actual h9 OS project, that would mean that anyone who used h9 could / would potentially use their own AWS account and lambdas. I was mostly just wondering about the one-time-lambda pattern.
lance Ticket 77 [ed: this ticket] is a step or a few steps more evolved than my one-time from the CLI idea. My idea was somewhere along the continuum between what we have now and what's described in 77.
dan lance: the funny thing is i originally was thinking more what you're thinking. but i kept thinking it was overkill somehow. but the more i've thought about it, the more i think we should deploy a lambda that does the deploy and that can be used as a hook if you want.
dan partly because that set's the stage for actually building out a Web client
lance And that's the natural end goal. Running any publish command manually is mostly unnecessary in the end
lance It's an unnecessary repetitive task
dan yes. and also error prone
dan accidentally publishing the wrong branch, forgetting to run the build command, etc.
lance good points