Alpine image and pipeline

[mattbell87]

This PR contains multiple features:

• New Alpine based boilerplate image with faster build times and smaller size
• Another complete cmfive image with included core and compiled theme. Based upon the boilerplate image
• GitHub Pipeline which automatically builds and tags the complete cmfive image and pushes it to GHCR
• Boilerplate docker-compose file now uses the pre-built image for development (files are still mapped in the same way)
• Extensive .dockerignore to remove unneeded files in image
• Various improvements to permission handling, also nginx runs as cmfive user
• Detailed container logs (php errors etc)

Checklist

• Boilerplate docker-compose brings up a fully working development container. No errors, theme compiling changes on the fly.
• Image can run in a container independent from the repo with no volumes/binds. No errors, theme visible.
• Image can run in a pod on Kubernetes. No errors, theme visible.
• Codespace-Dev-Box repo can use the new image correctly. No errors, theme visible.
• Codespace-Dev-Box tests pass (not sure if we can test this before merge?) get this going later
• Playwright tests work
• XDebug works Skipping this and investigating again later

TODO:

• Codespace-Dev-Box needs access to ghcr image
• Before Merge - Change tag in docker compose to develop branch
• Check live compiling on theme after permission changes
• Codespace-Dev-Box logs in to GHCR @Dane-2pi

[adam-buckley]

@adam-buckley my only issue with this is the idea of referencing the dev/feature branch of core during a build.

@chris-bateman what dev branch are you referring to?

On cmfive core?

RUN git clone --depth 1 https://github.com/2pisoftware/cmfive-core
This would clone master, not develop.

Either way for prod releases the branches are set in our CDK

[chris-bateman]

@adam-buckley my only issue with this is the idea of referencing the dev/feature branch of core during a build.

@chris-bateman what dev branch are you referring to?

On cmfive core?

RUN git clone --depth 1 https://github.com/2pisoftware/cmfive-core This would clone master, not develop.

Either way for prod releases the branches are set in our CDK

Yep aware it would clone master.
However since we are moving to docker files and potentially deploying said docker files to production. Setting the CDK may no longer be suitable. So that needs a rethink as well.

[adam-buckley]

Ah, noted. Something to discuss on Thursday

[mattbell87]

Here's a chart which hopefully helps explain the logic behind this:

https://lucid.app/lucidchart/0ab9565c-59aa-4a43-92ca-d8cddb0e0377/edit?viewport_loc=99%2C-532%2C4129%2C2122%2C0_0&invitationId=inv_3984acfe-5160-4aeb-811f-a80d33891147

So the main cmfive image in /.codepipeline/docker should contain something more ideal for production (so the main branch) baked in. But when we use the docker-compose file for development your local boilerplate and system/core are mapped in to the container (overriding the baked in stuff). So it will use the branch you have switched to locally (outside the container) in git.

[mattbell87]

@chris-bateman I tried another dev-box rebuild, still hits this?:

[chris-bateman]

@chris-bateman I tried another dev-box rebuild, still hits this?:

Did we auth boilerplate as well? I thought we only did core

[mattbell87]

Did we auth boilerplate as well? I thought we only did core

That image includes boilerplate + core

[mattbell87]

Hi @Dane-2pi, I've done some testing with this branch on codespace-dev-box and I've got it working.

Since the docker-compose file has a GHCR hosted image now it'll need to log in somewhere before doing the docker compose up. Here is some code you can use in the preBuildScript.sh:

# Log in to GHCR
echo "  logging into GHCR."  | tee -a $log_file
echo $GITHUB_TOKEN | docker login ghcr.io -u $GITHUB_USER --password-stdin

# docker compose up ...

You can implement this before this PR merges and it wont affect anything.

[Dane-2pi]

I'll target this branch and see what happens.

Does that command ask for a password from stdin? That doesn't work for a prebuild script at all. It could come from an envvar, but even that's not ideal

[mattbell87]

I'll target this branch and see what happens.

Does that command ask for a password from stdin? That doesn't work for a prebuild script at all. It could come from an envvar, but even that's not ideal

Stdin is left of the pipe (so echo'd in). It wont ask for input. I tested it on an existing codespace and it worked, but I haven't tried it on a fresh one.

[Dane-2pi]

Cool, I'll do that then. And then probably tear down half of my scripts...

…

On Tue, 20 Feb 2024, 8:11 am Matt Bell, ***@***.***> wrote: I'll target this branch and see what happens. Does that command ask for a password from stdin? That doesn't work for a prebuild script at all. It could come from an envvar, but even that's not ideal Stdin is left of the pipe (so echo'd in). It wont ask for input. I tested it on an existing codespace and it worked, but I haven't tried it on a fresh one. — Reply to this email directly, view it on GitHub <#103 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AXQ6LUXUFNTMWCY66YYI7ADYUO5W7AVCNFSM6AAAAABDL7Z2JKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJTGE3DENJWG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[mattbell87]

Playwright tests work just as before. I tested both with npm run test and with the vscode extension & trace viewer.

[Dane-2pi]

I can log in to GHCR, but the mysql container still isn't coming up in GH actions
Seems to be working fine in codespaces itself, so I'm happy with a merge.

[mattbell87]

2 things left

• @adam-buckley to close off review discussions
• @Dane-2pi to give me the OK that ghcr login is on develop branch of the codespace