-
Notifications
You must be signed in to change notification settings - Fork 318
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BREAKING CHANGE: Switch from sqlite3 to MySQL by default #323
Conversation
The best advice I can give here really is to mirror whatever Ghost CLI does, or as close as you can get. I don't mean to be vague, I can't remember what it does off the top of my head, but it's the best source of reference material for how Ghost likes things :) The very easiest way to go and see a default setup is to go to https://marketplace.digitalocean.com/apps/ghost and spin up a droplet. It'll show you everything we do to make a "production ready" install. Alternatively the code for the mysql extension in Ghost CLI lives here: https://github.com/TryGhost/Ghost-CLI/blob/main/extensions/mysql/index.js |
No need to apologize, that's helpful! That helps me lean more towards keeping it light and trusting the Ghost CLI defaults instead (since that will help us stay in the right place over time too). 👍 I'm setting |
For my own ability to keep track of things -- what's missing for this PR:
In this context, I personally love the "red banner" idea for sqlite3 installs since it'd make this a lot more obvious -- I think the only place that's different for container deploys than most other deploys is that users would be more likely to prefer environment variables for configuration than modifying JSON (so any documentation that the red banner links to might want to call out the environment variable configuration conversion specifically). 😅 |
I guess here is as good as anywhere for now -- for users who want to continue using the (explicitly unsupported!!!!) database__client: sqlite3
database__connection__filename: /var/lib/ghost/content/data/ghost.db |
For users who find this because their deployments broke, see #323 (comment) |
Changes: - docker-library/ghost@5de0cce: Merge pull request docker-library/ghost#323 from infosiftr/breaking-change-mysql - docker-library/ghost@ad07986: Update to 5.9.4, ghost-cli 1.22.0 - docker-library/ghost@da02fe1: Update to 5.9.3, ghost-cli 1.22.0 - docker-library/ghost@e2ba2f8: Update to 5.9.1, ghost-cli 1.22.0
Why do you release a breaking change with a minor version release? I was automatically updating my blogs with all new minor/patch versions but this broke all of them. Is it also possible to release a breaking change with a patch reelase? If so please don’t use semantic version numbers. Just number them independently. |
This was supposed to have been applied in |
Sorry, but that’s not a valid excuse. You are fixing a mistake with another mistake. When we had 5.0 release, I checked if I can just still use sqlite, and it just worked. Then I thought I’m safe until 6.0. If that was a mistake, you could fix it with 6.0. Otherwise what is the meaning of all these version numbers? |
The meaning of the version numbers is defined by the Ghost project, not our packaging of it. |
Then please rely on Ghost project and don't break something with a minor version as they do. Otherwise we always need to check every Docker release notes if it breaks something. Even patch versions... |
We had to either fix the broken users (#310) by setting ghost up in the supported manner (and thus break some users when they upgrade to While we do our best to minimize breaking changes in the Dockerization, users should be testing every version of every image that they pull before deploying it to production. |
Fixes #310
The intent is to merge this breaking change to coincide with the 5.9 upstream Ghost release so that we have a clean place to point users back to (#310 (comment)).
Here's a full diff of the generated configuration files:
cc @ErisDS
One thing I'm not sure about is whether we should still include
--db mysql
in theghost config
line so that we get an explicitclient: mysql
in that configuration. Further, I think it would probably also make sense to include--dbhost mysql
so that we also gethost: mysql
(instead of the default of "localhost" which isn't terribly useful in a container setup). Users would still need to supply their username/password/database, but at least this would be a starting point? Maybe even a default database of "ghost" or something? I don't want to make too many choices here that might end up in the same place as #310 😅