Removing docker CI test and add docker tutorial

.github/workflows/run-tests.yml

@@ -66,37 +66,6 @@ jobs:
       - name: Run linter for test generators
         run: make lint_generators
 
-  dockerfile-test:
-    runs-on: self-hosted
-    needs: preclear
-    services:
-      registry:
-        image: registry:2
-        ports:
-          - 5000:5000
-    steps:
-      - name: Checkout this repo
-        uses: actions/checkout@v3.2.0
-      - name: get git commit hash
-        id: git_commit_hash
-        shell: bash
-        run: |
-          echo "git_commit_hash=$(echo $(git log --pretty=format:'%h' -n 1))" >> $GITHUB_OUTPUT
-      - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v2
-        with:
-          driver-opts: network=host
-      - name: Build and push to local registry
-        uses: docker/build-push-action@v4
-        with:
-          context: .
-          file: ./docker/Dockerfile
-          push: true
-          tags: localhost:5000/consensus-specs-dockerfile-test:${{ steps.git_commit_hash.outputs.git_commit_hash }}
-      - name: Test the image by running the linter
-        run: |
-          docker run localhost:5000/consensus-specs-dockerfile-test:${{ steps.git_commit_hash.outputs.git_commit_hash }} make lint
-
   pyspec-tests:
     runs-on: self-hosted
     needs: [preclear,lint,codespell,table_of_contents]

docker/README.md

@@ -0,0 +1,20 @@
+## Docker related information
+
+This dockerfile sets up the dependencies required to run consensus-spec tests. The docker image can be locally built with:
+- `docker build ./ -t $IMAGE_NAME -f ./docker/Dockerfile`
+
+
+Handy commands:
+- `docker run -it $IMAGE_NAME /bin/sh` will give you a shell inside the docker container to manually run any tests
+- `docker run  $IMAGE_NAME make citest` will run the make citest command inside the docker container
+
+Ideally manual running of docker containers is for advanced users, we recommend the script based approach described below for most users.
+
+The `scripts/build_run_docker_tests.sh` script will cover most usecases. The script allows the user to configure the fork(altair/bellatrix/capella..), image_name(specifies the container to use), number of cores, preset type(mainnet/minimal) and test all forks flags. Ideally this is the main way that users interact with the spec tests, instead of running it locally with varying versions of dependencies.
+
+E.g:
+- `./build_run_test.sh --p mainnet --n 16` will run the mainnet preset tests with 16 threads
+- `./build_run_test.sh --a` will run all the tests across all the forks
+- `./build_run_test.sh --f deneb --n 16` will only run deneb tests on 16 threads
+
+Results are always placed in a folder called `./testResults`. The results are `.xml` files and contain the fork they represent and the date/time they were run at.