ACTIONS_RUNTIME_URL, ACTIONS_RUNTIME_TOKEN and ACTIONS_CACHE_URL environment variables are missing.

[quisse]

Github actions have undocumented environment variables named ACTIONS_RUNTIME_URL, ACTIONS_RUNTIME_TOKEN and ACTIONS_CACHE_URL. The actions/cache action relies on this to create the url to interact with for storing caches.
https://github.com/actions/toolkit/blob/1cc56db0ff126f4d65aeb83798852e02a2c180c3/packages/cache/src/internal/cacheHttpClient.ts#L33-L47

They all get populated over here

This is the cause of #285, #169 is linked.

[quisse]

The issue is still persistent afaik.

[jshwi]

Hi, I'm trying to understand the problem. Are these values dynamically set? Can they be manually set and read by act? If so what to?

[catthehacker]

Are these values dynamically set?

@jshwi Those environmental variables are only available to GitHub Actions runners, whether it be runner hosted by GitHub or self-hosted one.

Can they be manually set and read by act?

Probably.

If so what to?

No one knows, if it was that easy it would be fixed already.

Perhaps guys from GitHub (@joshmgross from https://github.com/actions/cache or @TingluoHuang from https://github.com/actions/runner, top committers) could chime in here, maybe give us some clues on how we could solve that issue.
I presume it won't be so easy as obtaining and just hardcoding those values since, most likely they are undocumented for a reason and the reason is it's supposed to work only on GitHub Actions service (but please, prove me wrong).
There is artefacts API https://docs.github.com/en/rest/reference/actions#artifacts which could be used to replace artefacts actions but I've not found anything regarding cache.

[jshwi]

Thank you, @catthehacker. I appreciate now having a better understanding of this.

[joshmgross]

👋 @catthehacker is correct, these variables are for internal APIs. If you wanted to manually set these values, you'd also likely need to simulate an internal service to support what these APIs are used for (like caching and artifacts).

[catthehacker]

@joshmgross Thank you very much for response! 😄 Unfortunately that is what I was afraid of.

So my idea was that act would spin up small http server available to its containers and work as transparent proxy. I might be able to draft something up whenever I get some more free time.

[anthonykawa]

I've built a very quick and simple express server that will simulate the download and upload endpoints of an artifact server here https://github.com/anthonykawa/artifact-server. If you want to use it to help understand building this into act, feel free. It only works if you specify the name and path inputs when uploading and downloading.

[catthehacker]

Thanks a lot @anthonykawa. Will take a look at it soon when I'll get time to develop artefact support.

[DrJume]

By default actions/cache uses Azure Blob Storage hosted by GitHub. It is possible to self-host Azure Blob Storage with https://github.com/Azure/Azurite.

[rickmark]

I've built a very quick and simple express server that will simulate the download and upload endpoints of an artifact server here https://github.com/anthonykawa/artifact-server. If you want to use it to help understand building this into act, feel free. It only works if you specify the name and path inputs when uploading and downloading.

This is great - I think we could probably even implement it in Go pretty quick and add it as an endpoint that is served directly by act locally to make common flows transparent (and eliminate the need of a container).

I might give that a try and submit a PR

[KnisterPeter]

It's already implemented in act

[rickmark]

Wow - was working on a reusable workflow branch and somehow missed that this was being provided, excuse the noise

[viotti]

The solution provided by @davetapley works on macOS. Using the --artifact-server-path does not.

$ mkdir /tmp/artifacts
$ act --artifact-server-path /tmp/artifacts

… (snip) …

[🏗 Continuous Integration/test-integration   ]   💬  ::debug::Artifact Url: http://192.168.1.23:34567/_apis/pipelines/workflows/1/artifacts?api-version=6.0-preview
| Create Artifact Container - Attempt 1 of 5 failed with error: connect EHOSTUNREACH 192.168.1.23:34567
| Create Artifact Container - Attempt 2 of 5 failed with error: connect EHOSTUNREACH 192.168.1.23:34567
| Create Artifact Container - Attempt 3 of 5 failed with error: connect EHOSTUNREACH 192.168.1.23:34567
| Create Artifact Container - Attempt 4 of 5 failed with error: connect EHOSTUNREACH 192.168.1.23:34567
| Create Artifact Container - Attempt 5 of 5 failed with error: connect EHOSTUNREACH 192.168.1.23:34567
[🏗 Continuous Integration/test-integration   ]   ❗  ::error::Create Artifact Container failed: connect EHOSTUNREACH 192.168.1.23:34567
[🏗 Continuous Integration/test-integration   ]   ❌  Failure - Main Upload coverage data
[🏗 Continuous Integration/test-integration   ] exitcode '1': failure
[🏗 Continuous Integration/test-integration   ] 🏁  Job failed

In the logs, 192.168.1.23 is the IP address of the en0 network interface. It seems that on macOS, the jobs' containers cannot reach the Go HTTP server. Probably due to virtualization that happens on that specific platform. Running Docker Desktop For Mac.

Firewall is off.

I've tried checking and clearing the Use the new Virtualization framework option on Docker Desktop, to no effect.

[ChristopherHX]

It seems that on macOS, the jobs' containers cannot reach the Go HTTP server

This must have changed in recent docker / macOS. I was able to connect to the external wifi address on macOS10.14 and windows 11.
Once I had to reinstall docker on windows 10 to restore access to a local network address.

Maybe the artifact server needs to be a docker container in the same network as the job container to resolve this.

[KnisterPeter]

@viotti Can you please post your workflow here? That would make the issue more complete and as well probably more reproduceable.
The artifact server was implemented to stay on the host so it could write into the hosts file system. When we move it into it's own container, it would be good to use a bind mount into the host FS I think. That should be possible with a non-breaking change.

As this issue is closed and also the title is not true anymore, I think it would make sense to move it over into a new issue describing the current problem.

[viotti]

@KnisterPeter sure. Here it goes.

name: 🏗 Continuous Integration

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

permissions:
  contents: read

jobs:
  lint:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - name: Set up Python 3.10
        uses: actions/setup-python@v4
        with: { python-version: '3.10' }

      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          python -m pip install flake8
        env:
          PIP_ROOT_USER_ACTION: ignore

      - name: Lint with flake8
        run: python -m flake8 --count --show-source --statistics *.py */*.py */*/*.py

  test-unitary:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - name: Set up Python 3.10
        uses: actions/setup-python@v4
        with: { python-version: '3.10' }

      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          python -m pip install pytest coverage
        env:
          PIP_ROOT_USER_ACTION: ignore

      - name: Run unitary tests
        run: python -m coverage run -m pytest tests/unitary
        env:
          COVERAGE_FILE: '.coverage.unitary'

      - name: Upload coverage data
        uses: actions/upload-artifact@v2
        with:
          name: coverage-data
          path: '.coverage.*'

  test-integration:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - name: Set up Python 3.10
        uses: actions/setup-python@v4
        with: { python-version: '3.10' }

      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          python -m pip install pytest coverage
        env:
          PIP_ROOT_USER_ACTION: ignore

      - name: Run integration tests
        run: python -m coverage run -m pytest tests/integration
        env:
          COVERAGE_FILE: '.coverage.integration'

      - name: Upload coverage data
        uses: actions/upload-artifact@v2
        with:
          name: coverage-data
          path: '.coverage.*'

  coverage:
    runs-on: ubuntu-latest

    needs: [ test-unitary, test-integration ]

    steps:
      - uses: actions/checkout@v3

      - name: Set up Python 3.10
        uses: actions/setup-python@v4
        with: { python-version: '3.10' }

      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          python -m pip install coverage[toml]
        env:
          PIP_ROOT_USER_ACTION: ignore

      - name: Download coverage data
        uses: actions/download-artifact@v2
        with:
          name: coverage-data

      - name: Combine coverage & fail if it's <100%.
        run: |
          python -m coverage combine
          python -m coverage report --fail-under=100  

@ChristopherHX I think the problem is the new M1/M2 chips, which are ARM. In this case the jobs will run within QEMU, since their images are x86. This might be causing networking issues. On macs with Intel chips the communication with the host probably works. This is just a guess though, I haven't tested to confirm.

[dahifi]

Same issue with M1, trying to use actions/download-artifact@v2. Getting ACTIONS_RUNTIME_TOKEN missing. Running the artifact server switches fails as well, communication timeout.

Might have to spin up an Ubuntu box somewhere to workaround this.

[ChristopherHX]

Just curios what happens if you use

ACTIONS_RUNTIME_URL=http://host.docker.internal:34567/ act --artifact-server-path out

On m1 macs with docker desktop together with enabling artifact server.
I don't have a m1/m2 mac hardware, only cirrus ci would allow me to test something on ci
Defining the env var ACTIONS_RUNTIME_URL allows you to customize the url, while artifact server is already enabled.

[valk]

davetapley Can you please share which docker-compose.yml did you use and how did you make it work for those like me?

[viotti]

@ChristopherHX just ran

ACTIONS_RUNTIME_URL=http://host.docker.internal:34567/ act --artifact-server-path /tmp/artifacts

Same issue:

[🏗 Continuous Integration/run-integration-tests   ]   ✅  Success - Main Run integration tests
[🏗 Continuous Integration/run-integration-tests   ] ⭐ Run Main Base64 encode code coverage data
[🏗 Continuous Integration/run-integration-tests   ]   🐳  docker exec cmd=[bash --noprofile --norc -e -o pipefail /var/run/act/workflow/5] user= workdir=
[🏗 Continuous Integration/run-integration-tests   ]   ✅  Success - Main Base64 encode code coverage data
[🏗 Continuous Integration/run-integration-tests   ] ⭐ Run Main Upload code coverage data
[🏗 Continuous Integration/run-integration-tests   ]   🐳  docker cp src=/Users/viotti/.cache/act/actions-upload-artifact@v3/ dst=/var/run/act/actions/actions-upload-artifact@v3/
[🏗 Continuous Integration/run-integration-tests   ]   🐳  docker exec cmd=[node /var/run/act/actions/actions-upload-artifact@v3/dist/index.js] user= workdir=
[🏗 Continuous Integration/run-integration-tests   ]   💬  ::debug::followSymbolicLinks 'true'
[🏗 Continuous Integration/run-integration-tests   ]   💬  ::debug::implicitDescendants 'true'
[🏗 Continuous Integration/run-integration-tests   ]   💬  ::debug::omitBrokenSymbolicLinks 'true'
[🏗 Continuous Integration/run-integration-tests   ]   💬  ::debug::followSymbolicLinks 'true'
[🏗 Continuous Integration/run-integration-tests   ]   💬  ::debug::implicitDescendants 'true'
[🏗 Continuous Integration/run-integration-tests   ]   💬  ::debug::omitBrokenSymbolicLinks 'true'
[🏗 Continuous Integration/run-integration-tests   ]   💬  ::debug::Search path '/Users/viotti/proj/integration.b64'
[🏗 Continuous Integration/run-integration-tests   ]   💬  ::debug::File:/Users/viotti/proj/integration.b64 was found using the provided searchPath
| With the provided path, there will be 1 file uploaded
[🏗 Continuous Integration/run-integration-tests   ]   💬  ::debug::Root artifact directory is /Users/viotti/proj
| Starting artifact upload
| For more detailed logs during the artifact upload process, enable step-debugging: https://docs.github.com/actions/monitoring-and-troubleshooting-workflows/enabling-debug-logging#enabling-step-debug-logging
| Artifact name is valid!
[🏗 Continuous Integration/run-integration-tests   ]   💬  ::debug::Artifact Url: http://host.docker.internal:34567/_apis/pipelines/workflows/1669643071/artifacts?api-version=6.0-preview
| Create Artifact Container - Attempt 1 of 5 failed with error: connect ECONNREFUSED 192.168.65.2:34567
| Create Artifact Container - Attempt 2 of 5 failed with error: connect ECONNREFUSED 192.168.65.2:34567
| Create Artifact Container - Attempt 3 of 5 failed with error: connect ECONNREFUSED 192.168.65.2:34567
| Create Artifact Container - Attempt 4 of 5 failed with error: connect ECONNREFUSED 192.168.65.2:34567
| Create Artifact Container - Attempt 5 of 5 failed with error: connect ECONNREFUSED 192.168.65.2:34567
[🏗 Continuous Integration/run-integration-tests   ]   ❗  ::error::Create Artifact Container failed: connect ECONNREFUSED 192.168.65.2:34567
[🏗 Continuous Integration/run-integration-tests   ]   ❌  Failure - Main Upload code coverage data
[🏗 Continuous Integration/run-integration-tests   ] exitcode '1': failure
[🏗 Continuous Integration/run-integration-tests   ] 🏁  Job failed

[ChristopherHX]

@viotti I see, docker changed the network stack in docker desktop macOS m1.

You get ECONNREFUSED instead of EHOSTUNREACH, different issue.

The problem is that the artifact server only listens to exactly one outbound ipv4 address, but docker is calling from another one.
In this case edit the code of act:

act/pkg/artifacts/server.go

Line 279 in 7754ba7

ip := common.GetOutboundIP().String()

ip := "0.0.0.0"

go build, then you have your act in the root folder.
I will create a PR, if it works.

[viotti]

@ChristopherHX indeed, that was an oversight on my part. I must admit I glossed over the error message and did not notice it had changed.

Anyways, I did as you asked, and everything worked. 👏 🎉

[🏗 Continuous Integration/run-integration-tests   ]   💬  ::debug::Artifact Url: http://host.docker.internal:34567/_apis/pipelines/workflows/1/artifacts?api-version=6.0-preview
[🏗 Continuous Integration/run-integration-tests   ]   💬  ::debug::URL is http://host.docker.internal:34567/_apis/pipelines/workflows/1/artifacts?api-version=6.0-preview&artifactName=code-coverage-data
[🏗 Continuous Integration/run-integration-tests   ]   💬  ::debug::Artifact code-coverage-data has been successfully uploaded, total size in bytes: 71935
| Artifact has been finalized. All files have been successfully uploaded!
| 
| The raw size of all the files that were specified for upload is 71935 bytes
| The size of all the files that were uploaded is 2457 bytes. This takes into account any gzip compression used to reduce the upload size, time and storage
| 
| Note: The size of downloaded zips can differ significantly from the reported size. For more information see: https://github.com/actions/upload-artifact#zipped-artifact-downloads 
| 
| Artifact code-coverage-data has been successfully uploaded!

[Vaitheesh-SS]

Hello!,

I'm trying to run a local test actions on my VM using nektos/act and I'm facing issues in reaching internet especially Failed to fetch http://archive.ubuntu.com/ubuntu/dists/focal/InRelease Could not resolve 'archive.ubuntu.com through my Proxy configured on my Ubuntu VM. The docker containers spin from act is unable to inject the Proxy Env's which I defined in ~/.docker/config.json but this works well when creating containers using docker cli

HTTPS_PROXY=http://localhost:3128 HTTP_PROXY=http://localhost:3128

Tried with act -j deploy --env HTTP_PROXY=http://localhost:3128 --env HTTPS_PROXY=http://localhost:3128 - no luck !

[TD5]

@viotti I see, docker changed the network stack in docker desktop macOS m1.

You get ECONNREFUSED instead of EHOSTUNREACH, different issue.

The problem is that the artifact server only listens to exactly one outbound ipv4 address, but docker is calling from another one. In this case edit the code of act:

act/pkg/artifacts/server.go

Line 279 in 7754ba7

ip := common.GetOutboundIP().String()

ip := "0.0.0.0"

go build, then you have your act in the root folder. I will create a PR, if it works.

It worked for me by modifying addr here:

act/pkg/artifacts/server.go

Line 290 in be4a147

Addr: fmt.Sprintf("%s:%s", addr, port),

Did anything come of the plan to submit a PR for this?

[ChristopherHX]

Did anything come of the plan to submit a PR for this?

Since then someone else added a cli flag to control this and you always have to override ACTIONS_RUNTIME_URL manually, so just add that flag.

So you can just use the latest release, [::0] is the ipv6 variant of 0.0.0.0.

ACTIONS_RUNTIME_URL=http://host.docker.internal:4322/ act --artifact-server-addr "[::0]" --artifact-server-port 4322 --artifact-server-path out

[fevrin]

After some trial-and-error-and-head-scratching when the recommended --artifact-server-path /tmp/artifacts argument didn't work for me, I found that this doesn't work specifically with v4 or higher of either actions/upload-artifacts or actions/download-artifacts.

act's own test file here works but still uses v2 of both actions; specifying v4 or higher for actions/upload-artifacts results in the following output (same error as what I was seeing in my own workflow):

gh act --artifact-server-path /tmp/artifacts -W .github/workflows/artifacts.yaml
...
[Test that artifact uploads and downloads succeed/test-artifacts] ⭐ Run Main actions/upload-artifact@v4
[Test that artifact uploads and downloads succeed/test-artifacts]   🐳  docker cp src=/home/fevrin/.cache/act/actions-upload-artifact@v4/ dst=/var/run/act/actions/actions-upload-artifact@v4/
[Test that artifact uploads and downloads succeed/test-artifacts]   🐳  docker exec cmd=[node /var/run/act/actions/actions-upload-artifact@v4/dist/index.js] user= workdir=
[Test that artifact uploads and downloads succeed/test-artifacts]   💬  ::debug::followSymbolicLinks 'true'
[Test that artifact uploads and downloads succeed/test-artifacts]   💬  ::debug::implicitDescendants 'true'
[Test that artifact uploads and downloads succeed/test-artifacts]   💬  ::debug::omitBrokenSymbolicLinks 'true'
[Test that artifact uploads and downloads succeed/test-artifacts]   💬  ::debug::followSymbolicLinks 'true'
[Test that artifact uploads and downloads succeed/test-artifacts]   💬  ::debug::implicitDescendants 'true'
[Test that artifact uploads and downloads succeed/test-artifacts]   💬  ::debug::matchDirectories 'true'
[Test that artifact uploads and downloads succeed/test-artifacts]   💬  ::debug::omitBrokenSymbolicLinks 'true'
[Test that artifact uploads and downloads succeed/test-artifacts]   💬  ::debug::Search path '/home/fevrin/home/path/to/artifact/world.txt'
[Test that artifact uploads and downloads succeed/test-artifacts]   💬  ::debug::File:/home/fevrin/home/path/to/artifact/world.txt was found using the provided searchPath
| With the provided path, there will be 1 file uploaded
[Test that artifact uploads and downloads succeed/test-artifacts]   💬  ::debug::Root artifact directory is /home/fevrin/home/path/to/artifact
| Artifact name is valid!
| Root directory input is valid!
[Test that artifact uploads and downloads succeed/test-artifacts]   ❗  ::error::Invalid token specified: Cannot read properties of undefined (reading 'replace')
[Test that artifact uploads and downloads succeed/test-artifacts]   ❌  Failure - Main actions/upload-artifact@v4
[Test that artifact uploads and downloads succeed/test-artifacts] exitcode '1': failure
[Test that artifact uploads and downloads succeed/test-artifacts] Cleaning up container for job test-artifacts
[Test that artifact uploads and downloads succeed/test-artifacts] 🏁  Job failed
Error: Job 'test-artifacts' failed

In my testing, I found that the latest releases of v3 for both actions seem to still work (v3.0.2 for download and v3.1.3 for upload), but per the changelog for those, it's clear that some changes will need to be made for act's support of v4 or higher:

The release of upload-artifact@v4 and download-artifact@v4 are major changes to the backend architecture of Artifacts. They have numerous performance and behavioral improvements.

ℹ️ However, this is a major update that includes breaking changes. Artifacts created with versions v3 and below are not compatible with the v4 actions. Uploads and downloads must use the same major actions versions. There are also key differences from previous versions that may require updates to your workflows.

https://github.com/actions/download-artifact/releases/tag/v4.0.0

I haven't looked into which changes would need to be made, but I just wanted to share this in case it's helpful for someone else in a similar spot.

[ChristopherHX]

@fevrin Please have a look at #2135 regarding v4 development.

v4 is a complete rewrite, but simplifies the artifact management compared to v3 and earlier

[fevrin]

@ChristopherHX nice, thanks for the pointer! I went ahead and subscribed to your issue 👍

I'll have to check into all those differences in v4 when I get a chance!

[VitusAcabado]

I know this issue is closed but this is how I was able to run it using artifact-server mentioned by @davetapley :

docker pull ghcr.io/jefuller/artifact-server:latest
docker run -d --name artifact-server -p 8080:8080 --add-host host.docker.internal:host-gateway -e AUTH_KEY=foo ghcr.io/jefuller/artifact-server:latest

• -d runs the container in detached mode; I prefer this so that the container runs in the background and I can continue using my terminal instance. You may omit this if you'd like.
• --add-host host.docker.internal:host-gateway allows you to access the container via http://host.docker.internal on your local network

I then create a directory to store the artifact files on my local based on where I run the act command. For simplicity I made one called out

mkdir out

So when running act, these are my commands:

act --env ACTIONS_RUNTIME_URL=http://host.docker.internal:8080/ --env ACTIONS_RUNTIME_TOKEN=foo --env ACTIONS_CACHE_URL=http://host.docker.internal:8080/ --artifact-server-path out

Things to note:

• value set for ACTIONS_RUNTIME_TOKEN == AUTH_KEY
• value set for --artifact-server-path flag == the directory you created

For context I am running act on Docker Desktop and Ubuntu on WSL2. I wasn't able to use the built in Golang server that act has and it's probably due to docker networking on WSL2.

[Ngel-Castro]

After some trial-and-error-and-head-scratching when the recommended --artifact-server-path /tmp/artifacts argument didn't work for me, I found that this doesn't work specifically with v4 or higher of either actions/upload-artifacts or actions/download-artifacts.

act's own test file here works but still uses v2 of both actions; specifying v4 or higher for actions/upload-artifacts results in the following output (same error as what I was seeing in my own workflow):

gh act --artifact-server-path /tmp/artifacts -W .github/workflows/artifacts.yaml
...
[Test that artifact uploads and downloads succeed/test-artifacts] ⭐ Run Main actions/upload-artifact@v4
[Test that artifact uploads and downloads succeed/test-artifacts]   🐳  docker cp src=/home/fevrin/.cache/act/actions-upload-artifact@v4/ dst=/var/run/act/actions/actions-upload-artifact@v4/
[Test that artifact uploads and downloads succeed/test-artifacts]   🐳  docker exec cmd=[node /var/run/act/actions/actions-upload-artifact@v4/dist/index.js] user= workdir=
[Test that artifact uploads and downloads succeed/test-artifacts]   💬  ::debug::followSymbolicLinks 'true'
[Test that artifact uploads and downloads succeed/test-artifacts]   💬  ::debug::implicitDescendants 'true'
[Test that artifact uploads and downloads succeed/test-artifacts]   💬  ::debug::omitBrokenSymbolicLinks 'true'
[Test that artifact uploads and downloads succeed/test-artifacts]   💬  ::debug::followSymbolicLinks 'true'
[Test that artifact uploads and downloads succeed/test-artifacts]   💬  ::debug::implicitDescendants 'true'
[Test that artifact uploads and downloads succeed/test-artifacts]   💬  ::debug::matchDirectories 'true'
[Test that artifact uploads and downloads succeed/test-artifacts]   💬  ::debug::omitBrokenSymbolicLinks 'true'
[Test that artifact uploads and downloads succeed/test-artifacts]   💬  ::debug::Search path '/home/fevrin/home/path/to/artifact/world.txt'
[Test that artifact uploads and downloads succeed/test-artifacts]   💬  ::debug::File:/home/fevrin/home/path/to/artifact/world.txt was found using the provided searchPath
| With the provided path, there will be 1 file uploaded
[Test that artifact uploads and downloads succeed/test-artifacts]   💬  ::debug::Root artifact directory is /home/fevrin/home/path/to/artifact
| Artifact name is valid!
| Root directory input is valid!
[Test that artifact uploads and downloads succeed/test-artifacts]   ❗  ::error::Invalid token specified: Cannot read properties of undefined (reading 'replace')
[Test that artifact uploads and downloads succeed/test-artifacts]   ❌  Failure - Main actions/upload-artifact@v4
[Test that artifact uploads and downloads succeed/test-artifacts] exitcode '1': failure
[Test that artifact uploads and downloads succeed/test-artifacts] Cleaning up container for job test-artifacts
[Test that artifact uploads and downloads succeed/test-artifacts] 🏁  Job failed
Error: Job 'test-artifacts' failed

In my testing, I found that the latest releases of v3 for both actions seem to still work (v3.0.2 for download and v3.1.3 for upload), but per the changelog for those, it's clear that some changes will need to be made for act's support of v4 or higher:

The release of upload-artifact@v4 and download-artifact@v4 are major changes to the backend architecture of Artifacts. They have numerous performance and behavioral improvements.
ℹ️ However, this is a major update that includes breaking changes. Artifacts created with versions v3 and below are not compatible with the v4 actions. Uploads and downloads must use the same major actions versions. There are also key differences from previous versions that may require updates to your workflows.

https://github.com/actions/download-artifact/releases/tag/v4.0.0

I haven't looked into which changes would need to be made, but I just wanted to share this in case it's helpful for someone else in a similar spot.

I was getting exact error and I was about to throw my computer out the window! downgrading the version from v4 to v3 did the magic!