I second your suggestion to use a config var to hold the key :) On Wednesday, April 3, 2013 9:53:33 AM UTC+1, Daniel Farina wrote: > > Hello, > > On Wed, Apr 3, 2013 at 1:11 AM, David Boyer > <[email protected]<javascript:>> > wrote: > > Looks like the ephemeral file system won't be an issue. I've read up > and it > > appears that it'll only lose any created files when the dyno is stopped > or > > restarted. That works fine for me since if the process is stopped / > > restarted, I wouldn't want those files anyway. Plus each batch would be > > independent, not requiring any from a previous batch of files. > > Your reading is correct. Many, many applications -- including quite a > few Heroku components -- rely on manipulating the file system within > the running container with the understanding that it will go away > after the container is destroyed. You can have a shot at knowing when > this is happening by treating SIGTERM in a program. The grace period > is some handful of seconds. > > > Just need to work out the SSH github deploy key needs to be configured > for > > heroku to have repository access for the push. Possibly this? > > I'd suggest (although it may seem bizarre) stuffing the key into a > config var if you do this, and then materializing it on the file > system to aid 'git push'. > > -- > fdr >
-- -- You received this message because you are subscribed to the Google Groups "Heroku" group. To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/heroku?hl=en_US?hl=en --- You received this message because you are subscribed to the Google Groups "Heroku Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
