Add support for Racket / Frog

[Exospheric]

NOTE: Racket sites output to the project root, and not in a production root subfolder of the project root. In other words, project root and production document root are one and the same.

Some details of the experience:
https://js.ipfs.io/ipns/QmZJBQBXX98AuTcoR1HBGdbe5Gph74ZBWSgNemBcqPNv1W/Zero-Config-CLI-to-Deploy-Static-Websites-to-IPFS.html

[Exospheric]

For static sites (like Racket) that deploy to the project root, EVERYTHING becomes part of the IPFS add, so will also need :

echo .env >> .ipfsignore

ipfs/kubo@759d3c1
(not sure if this means it isn't done. I can't find it in the reference docs)

Ref:
https://medium.com/interplanetary-gatsby/the-complete-beginners-guide-to-deploying-your-first-static-website-to-ipfs-103b27e8822e

After signing up and getting your API keys, go to your website’s directory and copy your keys into a .env file like so:

dwebsite/.env

IPFS_DEPLOY__PINATA__API_KEY=paste-the-api-key-here IPFS_DEPLOY__PINATA__SECRET_API_KEY=and-the-secret-api-key-here

⚠ You don’t want to make that information public ⚠, so when you’re doing this in a repository that you’re going to host publicly, make sure to add the.env file to your .gitignore:

echo .env >> .gitignore

[Exospheric]

Maybe the way to go is run the command from the parent of SITEROOT. In my case:

: sites/racket/frog/exospheric $ mv .env ../exospheric.env
cd ..
: sites/racket/frog $ ipd -e exospheric.env -p pinata exospheric/

basically because it seems your code is already set up to take a doc root name parameter.

I assume there could be more than one site in parent, thus more than one set of env files (different credentials for each site), thus the necessity for unique env file names, thus the need for an -e (environment) path switch.

I have to say, I don't understand how ipd knows the site has already been added to IPFS, or what its last CID is.

[agentofuser]

Nice catch on .ipfsignore. I hadn't really thought about that scenario. It does seem like it's not yet implemented. And js-ipfs tends to lag behind, so who knows when that support will be there.

The usecase of separating credentials from the site root can be achieved with #25.

Until then, you can try using a bash script like this:

#!/bin/sh
export $(egrep -v '^#' exospheric.env | xargs) && ipd -p pinata exospheric/

Still, it should be possible to call ipd ., so I'll look into that. Thank you for the helpful report!

[agentofuser]

I have to say, I don't understand how ipd knows the site has already been added to IPFS, or what its last CID is.

I'm not sure what you mean here. By "the last CID" you mean the one that just got deployed, or the one before that? ipfs-deploy doesn't keep deployment history at the moment. And the calls to the pinning services are synchronous, so when they return we know that it has been added to IPFS.

[Exospheric]

I do this from SITEROOT:

$ ipfs add -r . | tail -1 | cut -f2 -d ' ' | xargs ipfs name publish -ttl=1008h

This adds the whole site root (source, assets, and generated content) to IPFS, taking the content id of the site root folder and pubishes it to my PEERID for IPNS.

https://ipfs.io/ipns/QmZJBQBXX98AuTcoR1HBGdbe5Gph74ZBWSgNemBcqPNv1W/exactly-how-to-host-frog-over-ipfs.html