I was using --devmode to enable auth for testing with an external DB config. What options would I migrate to?

I was using --devmode to enable auth for testing with an external DB config. What options would I migrate to?

I would expect you'd use the same CLI options, but with --embedded-oidc instead of --devmode.

I was using --devmode to enable auth for testing with an external DB config. What options would I migrate to?

I would expect you'd use the same CLI options, but with --embedded-oidc instead of --devmode.

With the risk of being wrong I would say it will also need cargo run --bin trustd db migrate otherwise the DB tables won't be created. I also wonder if cargo run --bin trustd db migrate is needed only the first time I start the DB or that is a command that needs to be executed every time there are changes in the DB layer of Trustify

True. I was removing the "auto migration" feature of api --devmode in the same spirit of how #1063 removed the "auto import" feature. It all comes down to whether we want behavior in subcommands or options. Personally, I can learn to live with either or, but I don't love when we have both.

I'm willing to make an exception if it's useful, though. I would just prefer that the option name is specific, e.g. --migrate rather than generic, e.g. --devmode. That way, we don't have to keep trying to remember "wtf dev mode does".

Also, we might consider introducing a dev_mode fn similar to our pm_mode fn. That way, its behavior is explicit and contained within a single fn, rather than spread out through the code in various condition statements.

I find PM mode useful as a developer, but it's possible other developers don't, and we need to come up with some other bag of default features to facilitate their dev cycle.