{"action":"created","issue":{"url":"https://api.github.com/repos/pyrocms/pyrocms/issues/3526","labels_url":"https://api.github.com/repos/pyrocms/pyrocms/issues/3526/labels{/name}","comments_url":"https://api.github.com/repos/pyrocms/pyrocms/issues/3526/comments","events_url":"https://api.github.com/repos/pyrocms/pyrocms/issues/3526/events","html_url":"https://github.com/pyrocms/pyrocms/issues/3526","id":102035820,"number":3526,"title":"Artisan DB Commands Not Available If DB Not Already Set Up","user":{"login":"danhunsaker","id":1534396,"avatar_url":"https://avatars.githubusercontent.com/u/1534396?v=3","gravatar_id":"","url":"https://api.github.com/users/danhunsaker","html_url":"https://github.com/danhunsaker","followers_url":"https://api.github.com/users/danhunsaker/followers","following_url":"https://api.github.com/users/danhunsaker/following{/other_user}","gists_url":"https://api.github.com/users/danhunsaker/gists{/gist_id}","starred_url":"https://api.github.com/users/danhunsaker/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/danhunsaker/subscriptions","organizations_url":"https://api.github.com/users/danhunsaker/orgs","repos_url":"https://api.github.com/users/danhunsaker/repos","events_url":"https://api.github.com/users/danhunsaker/events{/privacy}","received_events_url":"https://api.github.com/users/danhunsaker/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2015-08-20T01:23:26Z","updated_at":"2015-08-20T02:47:12Z","closed_at":null,"body":"The current design of PyroCMS seems to rely on running the installer for every deployment at least once, or at least migrating DB contents across manually from an initial deployment to subsequent ones.  I can't run migrations until the database is already set up, which feels more than counter-intuitive, especially when the installer doesn't even actually run the migrations itself (or, well, at least doesn't record their run in the migrations table), causing them to fail on key constraints when run later to pull in updates.\r\n\r\nI deploy sites by pushing code to a server, which then automatically checks it out and runs a few maintenance commands (`composer update`, `artisan migrate`, and the like) before making it available to the web server.  Schema changes are kept in migrations, rather than SQL files, and data changes are shipped in seeds, as Laravel encourages.  This approach has worked well in the past, even in previous versions of Pyro built on CodeIgniter, so I'm surprised it isn't valid now.\r\n\r\nI suppose my real question is, if this is desired behavior, what is the recommended approach to automating new deployments of existing sites (such as the move from local dev into production)?"},"comment":{"url":"https://api.github.com/repos/pyrocms/pyrocms/issues/comments/132861355","html_url":"https://github.com/pyrocms/pyrocms/issues/3526#issuecomment-132861355","issue_url":"https://api.github.com/repos/pyrocms/pyrocms/issues/3526","id":132861355,"user":{"login":"RyanThompson","id":1099967,"avatar_url":"https://avatars.githubusercontent.com/u/1099967?v=3","gravatar_id":"","url":"https://api.github.com/users/RyanThompson","html_url":"https://github.com/RyanThompson","followers_url":"https://api.github.com/users/RyanThompson/followers","following_url":"https://api.github.com/users/RyanThompson/following{/other_user}","gists_url":"https://api.github.com/users/RyanThompson/gists{/gist_id}","starred_url":"https://api.github.com/users/RyanThompson/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/RyanThompson/subscriptions","organizations_url":"https://api.github.com/users/RyanThompson/orgs","repos_url":"https://api.github.com/users/RyanThompson/repos","events_url":"https://api.github.com/users/RyanThompson/events{/privacy}","received_events_url":"https://api.github.com/users/RyanThompson/received_events","type":"User","site_admin":false},"created_at":"2015-08-20T02:47:12Z","updated_at":"2015-08-20T02:47:12Z","body":"Hey there! Thanks for the input - a couple things though:\r\n\r\n1.) Pull latest and try installing again. I was an idiot and pushed a change last night that caused installer to NOT install addons. See https://github.com/anomalylabs/streams-platform/commit/b5b569f4d17ab4d7abad06f1751ed477d27e4019 (silly, I know).\r\n\r\n2.) Granted, you can NOT install the system without running the installer, I am working this weekend to finally finalize the installer. One of the features / changes is making the installer a.) 100% command driven and b.) event generated\r\n\r\nSo adding your own custom hooks to the installer for installation will be easy and deploying a headless install via a script / service will be easier since you will then be able to install with the CLI if you desire.\r\n\r\nThat said, all addons / streams rely entirely on migrations (they all have their own migrations folder) which has a short syntax for setting up streams, fields and assignments and can handle normal migrations too of course.\r\n\r\nSeeders are also supported through `php artisan db:seed --addon=vendor.addon_type.slug`\r\n\r\nThis will look for the seeder in the same namespace as a module:\r\n\r\n    ExampleModule // the module / addon class\r\n    ExampleModuleSeeder // the associated seeder\r\n\r\nFrom there you can run `$this->call(SeederClass::class);` as many times as you want to populate your data."}}