{"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":2,"created_at":"2015-08-20T01:23:26Z","updated_at":"2015-08-20T02:58:27Z","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/132867112","html_url":"https://github.com/pyrocms/pyrocms/issues/3526#issuecomment-132867112","issue_url":"https://api.github.com/repos/pyrocms/pyrocms/issues/3526","id":132867112,"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},"created_at":"2015-08-20T02:58:26Z","updated_at":"2015-08-20T02:58:26Z","body":"The installer seems to be running fine.  I've already run it locally, prior to the changes last night.  I was just hoping to avoid having to re-run it again when I deploy to production, because the idea is to remove the installer folder once it's been run..."}}