what if you wanted to deploy an app on EBS but god said Environment health has transitioned from Pending to Severe. ELB processes are not healthy on all instances đź’Ż
now thats its passed, although i still dont agree w/ it, excited to see what they put out / bring to fc
Oh wow interesting, I’ll keep an eye on the auctions 👀 Not entirely sure if I want in (too big of a decision to make on 3.5 hours of sleep after a sleepless week) but it’s an interesting prospect/DAO
Is very interesting to see all the people who didn’t vote here.
hvndcast proposal seemingly going to pass? 52-49 w/ 13 mins to go? Unless someone w 3 tokens comes out of the wood work seems like it’s already done p much
Yeah not entirely surprising I’ve so far seen it as a place for people who elon pushed away to flock to, like a mastodon type situation. And anti-crypto ppl def fit in there
Plot twist: dwr and v planted and crafted all this purple drama in order to attempt some crazy growth hack for FC
This isn’t meant to discredit anything about what the HVNDCAST team is/will be doing, i think the general idea and goal is solid and makes sense, I just don’t entirely know that now is the time to fund it, especially with (seemingly) not a lot to show for it right now, retroactive funding >>>
Irt B I think onboarding people from different communities is cool, and essential to the growth of any social platform, but at the same time, I don’t see why it makes sense to give $10k for that hope, when a lot of stuff is not available for the general public atm, I.e. permissionless signups not available.
Idk anything abt this proposal but after a quick skim I’m left A. Confused why it needs 5 ETH ($9.2k!!!) if no one the team is a programmer, then they’d have to outsource it which I’d imagine will cost a lot more than $10k B. Confused how this contributes positively to the protocol in its current state.
ok so irt turborepo/ebs thread i think i can just have shell scripts/github workflows (for manual & automated deployments) that: - prune the package specifically - build their dockerfile - zip them - upload to ebs - move onto next package then just do them sequentially since turborepo prunes write over themselves
Maybe if I copy the contents into a dir in docker then run pnpm install I’ll get the lock file and I can just do that? Idk how efficient or sane that is but could work?
Should probably preface this with the fact that it’s 1am and I’ve gotten dogshit sleep all week. Perhaps I’m being stupid about this all, I guess we shall see tomorrow
- push entire monorepo then somehow use a different Dockerfile based on app/env - somehow get the neccesary files for a standard Dockerfile (I.e. pnpm-lock.yaml) w/o using the prune command/relying on turborepo, then just pushing that as a standard dockerized app to EBS No clue how to go about either though :)
Goal here is to deploy each package/app to its own elastic beanstalk app/environment, however, to deploy on EBS, you upload a ZIP/artifact w/ your package (and the Dockerfile within), if it’s just the ZIP’d package, it doesn’t have any of the turborepo context. My two ideas thus far have been: (2/?)
Hmm dealing with an issue, anyone have ideas? Essentially, turborepo has a “prune” command to create an “out” folder that you gen/use in your Dockerfile, which works fine, but a caveat here is you have to run your dockerfile from the root turborepo dir, rather than running it from inside the package (1/?)