Support nektos/act for local GitHub actions testing

[justafish]

The Issue

Running DDEV with act is not currently possible

ddev config global --instrumentation-opt-in=false --omit-containers=ddev-ssh-agent
Could not connect to a Docker provider. Please start or install a Docker provider.

How This PR Solves The Issue

See nektos/act#724

Manual Testing Instructions

Create a new workflow with this action:

name: "Test Local Install"

on:
  push:
    branches:
      - master
  pull_request:
    types: [opened, synchronize, reopened]

concurrency:
  group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
  cancel-in-progress: true

jobs:
  Test-Local-Install:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: ./.github/actions/github-action-setup-ddev

Run act:

act -P ubuntu-latest=ghcr.io/catthehacker/ubuntu:runner-latest pull_request

Automated Testing Overview

Modification for locals

Related Issue Link(s)

Release/Deployment Notes

[rfay]

I have never gotten act to work for anything! Glad this can make it work here.

[tyler36]

Is there a way I can test this?

[rfay]

I think you should be able to do it by installing and using https://github.com/nektos/act

[tyler36]

Any progress here?

[freshworkx]

Why has this PR not yet found its way into the main branch? Is there anything against it? If not, please merge.

[rfay]

It hasn't gotten a review from anybody. Nobody has reported manually testing it with success.

I rebased it.

Please experiment with it and review it. It can be found at https://github.com/justafish/github-action-setup-ddev/tree/justafish/support-nektos-act

[freshworkx]

@rfay
First of all, you should add a note to the documentation that you have to use the image with runner as user:
act -P ubuntu-latest=ghcr.io/catthehacker/ubuntu:runner-latest

But unfortunately this does not work in my environment with Win11/WSL2 (Docker is installed inside WSL). When the command sudo chown runner:docker /var/run/docker.sock is running, the Docker instance on the host (wsl) crashes completely. I have to restart the entire wsl2 environment to be able to work again. I actually assumed that this command would only be executed within the ACT container. It looks like this is not working with my local user/group.

[rfay]

@freshworkx If I understand what you're saying you tested this PR and couldn't get it to work.

My own experience is that I've never gotten nektos/act to work for anything I've wanted it to work for, but @justafish must be succeeding...

[freshworkx]

@rfay
Thanks for your reply. To be clear, ACT itself works in my local environment. It is only in combination with the DDEV GitHub action that an error occurs. Maybe @justafish can report in which environment / installation she was able to test this successfully.

[justafish]

she has tested it on Linux and Mac M1

[penyaskito]

AFAIR this will change it on the host too, which can have side effects.

Maybe this is a better solution?
nektos/act#1798 (comment)

[freshworkx]

I did a little testing over the weekend. The solution from @penyaskito nektos/act#1798 (comment) seems to work without modifying the main.js. This solves the problem with the sudo chown command. However, there are other problems, such as with a PHP matrix. At the latest when starting up the 2nd PHP version there is an error: Failed to start xxx: unable to listen on required ports, port 443 is already in use.
The whole thing looks like not very sophisticated yet and I'm wondering whether this combination of act and ddev really makes sense, or whether you should continue to use composer scripts in the pipeline.

[jonaseberle]

Sorry I haven't noticed this PR.

But if I understand that correctly, we do not need this PR anymore and the solution for docker-in-docker is instead a different act configuration?

Although I have worked a lot with Github actions I have not used act yet. It seems to have a lot of traction currently.
But mind that you can always just copy this workflow into your project or fork it.

[tyler36]

Tried a quick play around but without luck.

This PR changed cause permission issues with Docker; which required a WSL restart to fix.

The closest I could get was using main branch and

• dynamically setting the socket
• specifiy a custom image

$ act --container-options "--group-add $(stat -c %g /var/run/docker.sock)" -P ubuntu-latest=ghcr.io/catthehacker/ubuntu:runner-latest
...
|  Container ddev-router  Running
| 
| Waiting 120s for additional project containers [ddev-cypress-ddev-l11-cypress] to become ready...
| 
| Successfully started cypress-ddev-l11
| 
| Your project can be reached at https://cypress-ddev-l11.ddev.site
| See 'ddev describe' for alternate URLs.
| 
[tests/✅ Cypress     ]   ✅  Success - Main ⚙️ DDEV

This appeared to work , as seen above with DDEV reporting the containers successfully started.
However, when it hit the next step in my yaml, ddev composer install, I got the following error:

[tests/✅ Cypress     ]   🐳  docker exec cmd=[bash -e /var/run/act/workflow/2] user= workdir=
| The repository at "/var/www/html" does not have the correct ownership and git refuses to use it:
| 
| fatal: detected dubious ownership in repository at '/var/www/html'
| To add an exception for this directory, call:
| 
|       git config --global --add safe.directory /var/www/html
| 
| Installing dependencies from lock file (including require-dev)
| Verifying lock file contents can be installed on current platform.
| Package operations: 113 installs, 0 updates, 0 removals
| 
| In Filesystem.php line 261:
|                                                                  
|   /var/www/html/vendor does not exist and could not be created:  

Sample workflow:

  e2e:
    name: '✅ Cypress'
    runs-on: ubuntu-latest
    steps:
      - name: '☁️ Checkout repository'
        uses: actions/checkout@v4

      - name: '⚙️ DDEV'
        uses: ddev/github-action-setup-ddev@v1

      - name: '⚙️ Project'
        run: |
          ddev composer install

[jonaseberle]

Thanks Tyler!
The initial PR I am really not comfortable with for changing ownership of /var/run/docker.sock based on an environment variable that's prone to persist when we are done.
And for the alternative option that Tyler tried we do not need the PR if I understand correctly.
That's why I would close here.