| [12:13:33] | <symbioquine[m]> | I'm trying to understand the context for these lines: https://github.com/farmOS/farmOS/blob/3a73ccf6360ba309ee657e2d645d29c239... |
| [12:13:33] | <symbioquine[m]> | Is there any reason we can't build both images in one step now that the Dockerfiles are combined? |
| [12:13:52] | <symbioquine[m]> | I'm worried about the "notably it does NOT override the default PROJECT_VERSION" part. |
| [12:15:33] | <symbioquine[m]> | The reason is that I'm trying to figure out what it would take to build the multi-platform images with buildx and having the two build steps there adds a bit of complexity. Plus it seems like we're doing duplicate work rebuilding the production image as part of building the dev image there... |
| [12:18:29] | <symbioquine[m]> | symbioquine[m]: It seems like that comment might be a bit misleading because the line #39 above doesn't override the `PROJECT_VERSION` either. |
| [12:18:56] | <symbioquine[m]> | * The motivation here is that I'm trying to figure out what it would take to build the multi-platform images with buildx and having the two build steps there adds a bit of complexity. Plus it seems like we're doing duplicate work rebuilding the production image as part of building the dev image there... |
| [12:19:48] | <symbioquine[m]> | * #39 above it doesn't override |
| [13:03:16] | <mstenta[m]> | Yea I think we can combine them now! |
| [13:03:46] | <mstenta[m]> | And yea, it would be a good time to update/move/remove that comment probably too. |
| [13:04:03] | <mstenta[m]> | It might still be worth highlighting that PROJECT_VERSION doesn't get overridden on the combined step |
| [13:04:59] | <mstenta[m]> | FYI I think I have an old buildx branch that I played around with a while ago... although it probably doesn't do anything beyond what you're doing |
| [13:05:19] | <mstenta[m]> | https://github.com/mstenta/farmOS/tree/2.x-buildx |
| [13:06:06] | <mstenta[m]> | Oh yea and that's related to this d.o issue we have open ("Needs Work"): https://www.drupal.org/project/farm/issues/3322762 |
| [13:07:07] | <mstenta[m]> | But that's ~2 years old at this point, so maybe very outdated |
| [13:08:04] | <mstenta[m]> | Looks like the approach I took was to add an entirely separate build-arm64 step... so your approach sounds better |
| [13:08:15] | <mstenta[m]> | (Assuming your goal is to build arm64... ?) |
| [13:08:54] | <symbioquine[m]> | Awesome! |
| [13:09:38] | <mstenta[m]> | Feel free to take over that d.o issue! |
| [13:09:55] | <mstenta[m]> | (or just make a PR and link to it) |
| [13:10:39] | <symbioquine[m]> | Yeah, thought I'd see if can get our GH build to produce and test against the major three architectures. (Arm32v7, Arm64v8, and amd64) |
| [13:11:52] | <mstenta[m]> | Not sure if this comment is still relevant, but: |
| [13:11:52] | <mstenta[m]> | > The other piece that hasn't been tested is the push to Docker Hub. I have a feeling that the way I have this structured will not work. I need to read up a bit more on what Docker Hub expects when pushing the multi-architecture images. Specifically: we will be pushing the same tag(s) for both architectures - and right now those will happen individually. Not sure if that's acceptable, or if the push needs to be combined somehow. |
| [13:12:10] | <mstenta[m]> | But that's probably just a limitation of the approach I took |
| [13:12:18] | <symbioquine[m]> | That should enable all the RPI sorts of devices to work out-of-the-box with the same official docker image tag - and no local `docker build` step. |
| [13:12:33] | <mstenta[m]> | That would be awesome |
| [13:15:21] | <symbioquine[m]> | I think to keep the caching in place, we basically need to a GH actions matrix to build/cache/test each arch separately, then in the push step we'd have a `docker manifest` step to create a single multiplatform manifest before pushing. |
| [13:15:48] | <mstenta[m]> | Yea I was wondering if we should test against all too |
| [13:16:22] | <mstenta[m]> | ACTION wishes we could get to the bottom of that sqlite3 testing issue - but that's a separate topic 🙄 |
| [13:16:31] | <symbioquine[m]> | For the testing, it would be cool to see the matrix fan out over two variables... |
| [13:16:53] | <mstenta[m]> | (i actually wondered recently if we should just drop "official" support for sqlite3) |
| [13:17:22] | <symbioquine[m]> | symbioquine[m]: Though I could also see the argument about it being overkill. |
| [13:17:30] | <symbioquine[m]> | mstenta[m]: Hmmm |
| [13:18:15] | <mstenta[m]> | SQLite3 support is nice to say we support, but in practice I don't recommend it |
| [13:18:26] | <mstenta[m]> | It's sort of just a freebie |
| [13:18:34] | <symbioquine[m]> | AFAIK the failures are more an artifact of the testing environment than an actual issue with sqlite support. |
| [13:18:49] | <mstenta[m]> | Yea |
| [13:19:08] | <mstenta[m]> | There's no good reason to drop support other than my own frustration with the tests 😆 |
| [13:19:25] | <symbioquine[m]> | It's handy for testing in some scenarios imho |
| [13:19:37] | <mstenta[m]> | True true |
| [13:20:55] | <symbioquine[m]> | https://github.com/symbioquine/farm-faux-cloud/blob/42809292366172387278... |
| [13:22:57] | <symbioquine[m]> | Seems like we should "test all the things" within reason until we get a signal we need to cut back... |
| [13:23:20] | <mstenta[m]> | I agree |
| [13:23:35] | <mstenta[m]> | I'm just grumpy about the tests :-P |
| [13:23:44] | <symbioquine[m]> | It's basically Microsoft subsidizing farmers having good software. |