Draft
Conversation
Show users how to chain filecoin-project/filecoin-pin/upload-action after this action to archive the same CAR to Filecoin, without repacking or CID drift. Depends on the upstream change that treats a `.car` `path` as a pre-built CAR (filecoin-project/filecoin-pin#410).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Important
do not merge, opening to illustrate how we can keep filecoin-pin details separate, without any maintenance burden.
What
Adds a
Archiving to FilecoinREADME section showing how to chainfilecoin-project/filecoin-pin/upload-actionafter this action so the same CAR is archived to Filecoin. Noaction.ymlchanges.Why composition, not embedding
I prototyped embedding Filecoin Pin as a first-class provider and it does not look feasible in current state of upstream code:
action.yml. Filecoin Pin is ~400 lines of Node.js (Synapse, USDFC top-ups, PDP, IPNI, retry). Not sane. We could revisit if upstream provides better CLI tooling that blackboxes process end-to-end.checks: write,pull-requests: write,actions: readfor its own check run / PR comment / artifact cache. Every caller would have to grant those, even if they never enable Filecoin. Not feasible, bad opsec.Composition (this PR) scopes all four to users who actually opt in.
Today vs. after upstream #410
Example works today, but upstream repacks the CAR so the Filecoin CID will differ from ours. Once filecoin-project/filecoin-pin#410 ships, switching to
path: build.carmakes the CIDs identical.Revisit when
Filecoin Pin ships a shell-level one-liner comparable to
ipfs pin remote add(Pinata) oraws s3 cp --metadata 'import=car'(Filebase). Then embedding becomes cheap and the argument flips.