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
fix: provide sqlite 3.45 for drupal11, fixes #6110 #6137
Conversation
Download the artifacts for this pull request:
See Testing a PR. |
works. quickly followed the quickstart for d11
and
on line 24 to 31. so looks good. |
Have been reading the discussions and It's quite unfortunate d11 picked that version. Specially since we will need to track any security advisory in sqlite, as updating that one becomes manual with this PR. |
pkg/ddevapp/config.go
Outdated
drupalVersion, err := GetDrupalVersion(app) | ||
if err == nil && drupalVersion == "11" { | ||
extraWebContent = extraWebContent + "\n" + fmt.Sprintf(` | ||
### Drupal 11+ requires a miniumum sqlite3 version (3.45 currently) |
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.
This looks as clean as it can be 🥇
// for setting requirements. | ||
// It can only work if there is configured Drupal8+ code | ||
func getDrupalVersion(app *DdevApp) (string, error) { | ||
func GetDrupalVersion(app *DdevApp) (string, error) { |
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.
Wondering if exposing this is "irreversible" now. Not sure if we have a "public" api. Even if we know this works, wondering if that implies requiring more specific tests.
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's just globally available.
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.
Yes, wondering if we have a "ddev as a library" contract where anything that is exposed won't be hidden/renamed later and we consider it public api.
E.g. in https://github.com/ddev/ddev/pull/6118/files (as go doesn't have optional args), I thought maybe could be better to just change the signature and require the "optional" defaultTo flag.
This might become more relevant if we decide to build a TUI wrapping ddev instead of replacing our current ddev app.
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've never been ambitious enough to worry about that. In this case of a TUI, it would not really be a wrapper I wouldn't think, but integrated into DDEV. Not sure.
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.
Tested, all good 👍
Co-authored-by: Stanislav Zhuk <stasadev@gmail.com>
The Issue
Drupal 11 added an arbitrary sqlite3 version constraint that is hard to meet with Debian Bookworm
How This PR Solves The Issue
Install it using debs from Debian 13 Trixie
Manual Testing Instructions
ddev exec sqlite3 --version
should show 3.45.1Automated Testing Overview
It's a sad location, but I added a test in TestDdevFullSiteSetup for drupal 11 that is specific to this case. I'm open to better suggestions. It could have its own test, but that seemed even worse.
Related Issue Link(s)