-
Notifications
You must be signed in to change notification settings - Fork 1.2k
feat: allow daemon to init and start in a single cmd #2428
Conversation
It would be nicer if it just The new user experience is: $ ipfs
/// blah blah blah blah long thing don't make me read
$ ipfs daemon
// NO! ERROR! Run this other command
$ ipfs init
// THANK YOU HUMAN
$ ipfs daemon
... |
What I'm saying is, I think we should just Running |
This is really cool and I'm excited to see the speed increase in our CLI tests. However, I'm struggling to think of a reason why we wouldn't want So, how about: remove |
I agree it should be initialized by default. However, the one reason not to do this is that the current behavior prevents the daemon from being run against the wrong repo. In my case, I always set an explicit repo with But yeah, there's really no reason to not auto initialize. |
84a8b34
to
0decf84
Compare
Should we get this in as is or change it ? |
I think we should change this to initialise by default instead of adding extra flags. |
done can we get this merged ? |
8471234
to
5e39dc7
Compare
Also tag last successful build and ensure we do not get stealth multiaddr@v7
test/cli/daemon.js
Outdated
@@ -265,4 +282,34 @@ describe('daemon', () => { | |||
expect(err.stdout).to.include(`Node.js version: ${process.versions.node}`) | |||
} | |||
}) | |||
|
|||
it('should init by default if not already', async function () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does this test assert that the daemon auto-initialised it's own repo?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ipfs daemon cmd throws if there is no repo initialised. So if this test passes we should be good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should also assert that the repo was created after the command has run, otherwise it doesn't actually test anything other than that the daemon process was killed. Check the repo directory exists or something like that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My reasoning is to not over test stuff, here we are testing the daemon
command and logic, init
was added to that logic but we should only test that it gets ran not that init
works correctly we have other tests for that.
This test will fail if init isn't ran or if init fails internally, which is the scope i wanted when i wrote the test.
Makes sense ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess its a bit hidden because init is on by default and if init doesn't work daemon also fails completely but still we have other tests that make sure init creates a repo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this test doesn't test anything not covered by other tests it should be removed.
If it does test something not covered by other tests, it should contain assertions to prove the functionality being tested works as expected.
Too many of our tests don't actually test anything, they just ensure that nothing on the happy path explodes so aren't all that useful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@achingbrain is right. Tests should be both valuable and informative. If it requires one to know that the test is testing for the program not to blow up in some weird situation, at least that needs to be well documented and not just live in one persons brain.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the assertion is this if (stdout.includes('Daemon is ready')) {
i agree this isn't the best way to do things and i will improve this in a near future, but this is the way we assert a daemon ran successfully in the others tests.
this is the first test to work without calling ipfs(init)
.
either i remove the test or change the name to something more informative like 'should start the daemon and init automatically without calling init first' or something else but i don't think testing for the repo is useful here.
im open to suggestions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestions were:
- Document it with code comments
- Assert that the repo was created as part of the test
This PR aligns `ipfs init` and `ipfs daemon` with go-ipfs. ipfs/kubo#6489 `ipfs init` changed to accept a file path as an argument `ipfs daemon` changed to support `--init` and `--init-config` options. Now we can do `ipfs daemon --init --init-config /path/to/custom-config` refs: ipfs/js-ipfsd-ctl#303
5e39dc7
to
d134357
Compare
BREAKING CHANGE: swarm tests need promise based setup check PRs below the following PRs add support async setup: ipfs-inactive/js-ipfs-http-client#1105 ipfs/js-ipfs#2428
this can be improve directly in aegir
This PR aligns
ipfs init
andipfs daemon
with go-ipfs.ipfs/kubo#6489
ipfs init
changed to accept a file path as an argumentipfs daemon
changed to support--init
and--init-config
options.Now we can do
ipfs daemon --init --init-config /path/to/custom-config
refs:
ipfs/js-ipfsd-ctl#303
Missed the breaking change in the commit msg...
BREAKING CHANGE:
ipfs init
first positional argument is a path to a file instead of a JSON string. Although the previous version was completely broken.