Assumptions about init-docs hashes

[ghost]

I can't quite pin down what the issue is, but I think it's something about the assumptions js-ipfs-api makes about the init-docs hashes. My observations:

• I updated the init-docs in go-ipfs, and the js-ipfs build is failing. [1] It looks like only the .refs tests fail, while other tests seem to add the init-docs themselves and use the hash resulting from that.
• The whole npm test run works fine locally. Does js-ipfs-api use the go-ipfs from $PATH? Does it generate ephemeral fs-repos? I do have the new init-docs in my ~/.ipfs fs-repo, and the tests might use that fs-repo in one spot and succeed because of that?

I don't have a good idea but it's blocking ipfs/kubo#2997 which is a trivial PR in itself but turned into a yak shaving.

[1] http://ci.ipfs.team:8111/viewLog.html?buildId=5376&buildTypeId=GoIpfs_JsIpfsApiTests&tab=buildLog#_focus=1948

[daviddias]

@lgierth yeah, some or the 'old' tests use the assumption that the repo is already populated with something. We just need to make it so that it uses the files.add call to populate the repo for the tests.

[whyrusleeping]

@diasdavid @dignifiedquire any update here?

[dignifiedquire]

@whyrusleeping I will take a look at this today

[victorb]

Kind of related, maybe we should have a separate repository with test data we can use across the organization, with some json structure + files that we can use a central point for the data? Would be useful for existing projects + if people want to write new implementations in different languages/api connections