mirror of
https://github.com/nektos/act.git
synced 2026-04-26 01:15:51 +03:00
[GH-ISSUE #329] ACTIONS_RUNTIME_URL, ACTIONS_RUNTIME_TOKEN and ACTIONS_CACHE_URL environment variables are missing. #231
Labels
No labels
area/action
area/cli
area/docs
area/image
area/runner
area/workflow
backlog
confirmed/not-planned
kind/bug
kind/discussion
kind/external
kind/feature-request
kind/question
meta/duplicate
meta/invalid
meta/need-more-info
meta/resolved
meta/wontfix
meta/workaround
needs-work
pull-request
review/not-planned
size/M
size/XL
size/XXL
stale
stale-exempt
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/act#231
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @quisse on GitHub (Aug 3, 2020).
Original GitHub issue: https://github.com/nektos/act/issues/329
Github actions have undocumented environment variables named
ACTIONS_RUNTIME_URL,ACTIONS_RUNTIME_TOKENandACTIONS_CACHE_URL. The actions/cache action relies on this to create the url to interact with for storing caches.github.com/actions/toolkit@1cc56db0ff/packages/cache/src/internal/cacheHttpClient.ts (L33-L47)They all get populated over here
This is the cause of #285, #169 is linked.
@github-actions[bot] commented on GitHub (Nov 25, 2020):
Issue is stale and will be closed in 7 days unless there is new activity
@quisse commented on GitHub (Nov 25, 2020):
The issue is still persistent afaik.
@DivoK commented on GitHub (Dec 20, 2020):
Any news about this problem? Came here from #285
@ayozemr commented on GitHub (Jan 19, 2021):
Coming from https://github.com/nektos/act/issues/169
@jshwi commented on GitHub (Jan 24, 2021):
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 commented on GitHub (Jan 24, 2021):
@jshwi Those environmental variables are only available to GitHub Actions runners, whether it be runner hosted by GitHub or self-hosted one.
Probably.
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 commented on GitHub (Jan 25, 2021):
Thank you, @catthehacker. I appreciate now having a better understanding of this.
@joshmgross commented on GitHub (Jan 25, 2021):
👋 @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 commented on GitHub (Jan 26, 2021):
@joshmgross Thank you very much for response! 😄 Unfortunately that is what I was afraid of.
So my idea was that
actwould 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.@github-actions[bot] commented on GitHub (Feb 26, 2021):
Issue is stale and will be closed in 14 days unless there is new activity
@anthonykawa commented on GitHub (Feb 26, 2021):
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 commented on GitHub (Feb 26, 2021):
Thanks a lot @anthonykawa. Will take a look at it soon when I'll get time to develop artefact support.
@github-actions[bot] commented on GitHub (Mar 29, 2021):
Issue is stale and will be closed in 14 days unless there is new activity
@ivan4th commented on GitHub (Mar 29, 2021):
Needed for artifacts, please don't close
@ChristopherHX commented on GitHub (May 2, 2021):
I have built (this year) a whole
actlike clone which have a builtin artifact and cache server.My clone defines all these variables and is able to use the official self-hosted runners. This source code is incompatible with act, because I used the same language as the official runner to reduce rewriting code and maintenance time.
My first goal wasn't to run them locally like act, but on a raspberry pi with a github like server (https://github.com/go-gitea/gitea).
@chevdor commented on GitHub (Jun 4, 2021):
I am testing the option from @anthonykawa (PRs incoming) and it seems that
actdoes not properly honor the config:I did set an ENV defined as
ACTIONS_CACHE_URL=localhost:8080.We can see in the logs that we connect to it
::debug::Resource Url: localhost:8080_But then suddenly,
actcomplains about :80 not being available...@jgsqware commented on GitHub (Jul 1, 2021):
@chevdor the runner is running inside docker. I guess the @anthonykawa server is running on your machine, thus
localhostrefer to docker localhost and not yours.you have to expose the service to make it accessible from inside a container
@almed4 commented on GitHub (Jul 8, 2021):
I'm trying to use @actions/cache in a node script run in a composite steps action, and it does not have these env vars on an ubuntu-latest github-hosted runner. Am I going to be out of luck here, or is there a way to emulate the @actions/cache action manually?
@Erriez commented on GitHub (Aug 16, 2021):
Did someone get this up and running in combination with
actions/cache@v2? I'm running out of ideas to share Docker images between jobs withAct. Any suggestion?@catthehacker commented on GitHub (Aug 16, 2021):
There is no plan to support that action at all.
What do you mean? All your images should be stored on your Docker host, there is no need to cache them.
@Erriez commented on GitHub (Aug 16, 2021):
It looks like some people tried to run a local server for caching.
Two things:
cache-fromandcache-towithout luck inAct.Do you have a suggestion / hint?
@catthehacker commented on GitHub (Aug 16, 2021):
There is nothing that needs to be done except that jobs need to depend on each other but it would be much easier to tell what is wrong if you showed your repo/workflow.
@Erriez commented on GitHub (Aug 16, 2021):
Thanks for your quick reply. I'm optimizing Github Actions CI build/test/deployment flow for a full stack email server using multiple Docker containers, project Mailu.
Github Actions CI config file:
https://github.com/Mailu/Mailu/blob/master/.github/workflows/CI.yml
The goal is to build and test the Docker images locally before providing a PR. This
Actproject seems to be the right tool for us to do this and speed-up the development process.This
CI.ymlflow usesactions/cache@v2by default and works perfect on Github, but not locally withactas mentioned in this issue:It tries to contact the cache service via an API which is not available on a local machine. For this reason, there is never a cache hit and always rebuilds all images. It looks like @anthonykawa tried to create such server to upload/download images, but I could not get the up and running and hopefully he can answer the question how he used it.
When the build has been completed, it exports the created images to a
tarfile to pass it to the next test jobs. This is time consuming process, but required when containers are re-created from scratch at the start of each job. Alternatively, the images should be pushed to a registry, but is not preferred when the images are untested.I've created a test case which is available here:
https://github.com/Erriez/act-testcase
Simply clone the project and run
actmultiple times. The image is rebuild from scratch at each run.Q1) How can this optimized for
actto skip the build when the image is not changed and already available asactions/cache@v2cannot be used?Q2) How can the build images used in a second
testjob usingact?@catthehacker commented on GitHub (Aug 16, 2021):
Add
if: ${{ !env.ACT }}to all steps that areactions/cache,run: docker save ...andrun: docker load ...Because you are using buildx action that creates new builder for each run and each run cache is exclusive to that builder.
If the buildx builder is the same each run, cache will be re-used.
@Erriez commented on GitHub (Aug 16, 2021):
@catthehacker Thanks for your valuable reply.
Adding
if: ${{ !env.ACT }}to theuses: actions/cache@v2entries skips this unsupported action which save time on the timeout.You're right: A cache build works fine for a normal
docker buildcommand. I was not aware of this.I'll check how to configure the buildx builder to reuses the same cache every time. I'll investigate this further.
docker saveanddocker loadcan be used within the same job and works.However,
actions/cache@v2was used to share the images between jobs. Is an alternative available (without pushing to a registry)? For example by using a volume of the act build container?@catthehacker commented on GitHub (Aug 16, 2021):
act --env DOCKER_BUILDKIT=0should work.There is no need for any kind of volumes in
act. All Docker work is saved either on host or in builder containers.@Erriez commented on GitHub (Aug 17, 2021):
Unfortunately it does not work.
@catthehacker I try to find an alternative for
actions/cache: Do you have ideas for the following questions?act? I need to pass build artifacts to the next job.actand the host? For example to share a certificate required to login to a local registry?@nschwermann commented on GitHub (Aug 29, 2021):
Also running into this issue. I have two jobs the first job generates files for second job and saves them using upload-artifact@v2 but I can't seem to get it to work in act
@simonhkswan commented on GitHub (Sep 21, 2021):
@chevdor did you have any more luck with this? I found if I used the server from @anthonykawa with in a simple Docker container
And ran
with
ACTIONS_CACHE_URL=localhost/(i'm not sure how much docker likes ':' placed in environment variables but we can just let it default to port 80.)Then it would try to connect but get a 400
... and now I'm stuck at this point.
@econchick commented on GitHub (Oct 6, 2021):
@simonhkswan @chevdor I got @anthonykawa 's server to work!
With the Dockerfile, I added
ENV AUTH_KEY=foo(can be whatever). When running the docker image, I dropped the-dflag so I could see any logs.Then in another terminal, I ran
actlike so:where
ACTIONS_RUNTIME_TOKENis the same as theAUTH_KEYset in the dockerized server, and thehttp://is needed for both URLs.@ClientCrash commented on GitHub (Oct 7, 2021):
With the arguments
act --env ACTIONS_RUNTIME_TOKEN=foo --env ACTIONS_RUNTIME_URL=http://localhost/everything works fine until i reach the artifacts part.
Create Artifact Container - Attempt 1 of 5 failed with error: connect ECONNREFUSED 127.0.0.1:80Do i have to run some kind of server or something? Is there a solution provided with act?
@catthehacker commented on GitHub (Oct 7, 2021):
Please read the thread.
@davetapley commented on GitHub (Oct 14, 2021):
It works! 🎉
I took @simonhkswan's sample
Dockerfile🙏🏻 and pushed toghcr.io/jefuller/artifact-server:latest.Then I added to
docker-compose.yml:The added (per @econchick 🙏🏻 ) to
.actrc:Sample of upload:
and download:
@davetapley commented on GitHub (Oct 14, 2021):
Update since playing with ⬆️
If you run
upload-artifactmultiple times it will just keep 'adding' to the artifact.One hacky workaround is to
docker execrm -r '/usr/src/app/1'inartifact-server,but a better solution is to set
GITHUB_RUN_ID(which I found here), e.g:@catthehacker would you accept a PR to set that ⬆️ to a random (or incrementing) number each run?
I presume when running on GitHub Actions it changes each run.
@catthehacker commented on GitHub (Oct 17, 2021):
It works as it should. If you need to change it, you can use the envvar
@sp-ricard-valverde commented on GitHub (Oct 29, 2021):
I belive @simonhkswan @chevdor are expecting the
actions/cache@v2to work with @anthonykawa server(by what I can see in their execution log request urls), but actually the actions that do work areactions/upload-artifact@v2andactions/download-artifact@v2.@catthehacker commented on GitHub (Oct 29, 2021):
https://github.com/nektos/act/issues/329#issuecomment-899692430
@BevanR commented on GitHub (Dec 7, 2021):
If you're following this thread for a solution to the
actions/cacheto develop GHA workflows locally so that you can get faster feedback when you test-run on your changes to GHA workflow yaml files, see https://github.com/nektos/act/issues/285#issuecomment-987550101@RafalSkolasinski commented on GitHub (Jun 16, 2022):
Just read this thread, dummy question: what blocks us from just including anthonykawa's server to enable artifact feature by default in act?
@KnisterPeter commented on GitHub (Jun 16, 2022):
There is already a server implemented, it just needs to be enabled via flag. 😉
@luixo commented on GitHub (Jul 18, 2022):
If you are using
nektos/actwithactions/upload-artifactandactions/download-artifact, artifact server is already implemented inact(though it's not mentioned in this issue how to run it).Just use
--artifact-server-pathoption.It is used like this:
--artifact-server-path /tmp/artifacts(don't forget tomkdir /tmp/artifacts).@DrJume commented on GitHub (Oct 18, 2022):
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 commented on GitHub (Oct 31, 2022):
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
actlocally to make common flows transparent (and eliminate the need of a container).I might give that a try and submit a PR
@KnisterPeter commented on GitHub (Oct 31, 2022):
It's already implemented in act
@rickmark commented on GitHub (Oct 31, 2022):
Wow - was working on a reusable workflow branch and somehow missed that this was being provided, excuse the noise
@viotti commented on GitHub (Nov 8, 2022):
The solution provided by @davetapley works on macOS. Using the
--artifact-server-pathdoes not.In the logs, 192.168.1.23 is the IP address of the
en0network 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 commented on GitHub (Nov 8, 2022):
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 commented on GitHub (Nov 8, 2022):
@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 commented on GitHub (Nov 8, 2022):
@KnisterPeter sure. Here it goes.
@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 commented on GitHub (Nov 14, 2022):
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 commented on GitHub (Nov 14, 2022):
Just curios what happens if you use
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_URLallows you to customize the url, while artifact server is already enabled.@valk commented on GitHub (Nov 22, 2022):
davetapley Can you please share which
docker-compose.ymldid you use and how did you make it work for those like me?@viotti commented on GitHub (Nov 28, 2022):
@ChristopherHX just ran
Same issue:
@ChristopherHX commented on GitHub (Nov 28, 2022):
@viotti I see, docker changed the network stack in docker desktop macOS m1.
You get
ECONNREFUSEDinstead ofEHOSTUNREACH, 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:
github.com/nektos/act@7754ba7fcf/pkg/artifacts/server.go (L279)go build, then you have youractin the root folder.I will create a PR, if it works.
@viotti commented on GitHub (Nov 28, 2022):
@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. 👏 🎉
@Vaitheesh-SS commented on GitHub (Jan 22, 2023):
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.jsonbut this works well when creating containers using docker cliHTTPS_PROXY=http://localhost:3128 HTTP_PROXY=http://localhost:3128Tried with
act -j deploy --env HTTP_PROXY=http://localhost:3128 --env HTTPS_PROXY=http://localhost:3128- no luck !@TD5 commented on GitHub (Feb 17, 2023):
It worked for me by modifying
addrhere:github.com/nektos/act@be4a1477a5/pkg/artifacts/server.go (L290)Did anything come of the plan to submit a PR for this?
@ChristopherHX commented on GitHub (Feb 17, 2023):
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 of0.0.0.0.@fevrin commented on GitHub (Jan 19, 2024):
After some trial-and-error-and-head-scratching when the recommended
--artifact-server-path /tmp/artifactsargument didn't work for me, I found that this doesn't work specifically with v4 or higher of eitheractions/upload-artifactsoractions/download-artifacts.act's own test file here works but still uses v2 of both actions; specifying v4 or higher foractions/upload-artifactsresults in the following output (same error as what I was seeing in my own workflow):In my testing, I found that the latest releases of v3 for both actions seem to still work (v3.0.2 for
downloadand v3.1.3 forupload), but per the changelog for those, it's clear that some changes will need to be made foract's support of v4 or higher: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 commented on GitHub (Jan 19, 2024):
@fevrin Please have a look at https://github.com/nektos/act/issues/2135 regarding v4 development.
v4 is a complete rewrite, but simplifies the artifact management compared to v3 and earlier
@fevrin commented on GitHub (Jan 19, 2024):
@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 commented on GitHub (Jan 23, 2024):
I know this issue is closed but this is how I was able to run it using
artifact-servermentioned by @davetapley :-druns 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-gatewayallows you to access the container viahttp://host.docker.internalon your local networkI 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
outSo when running
act, these are my commands:Things to note:
ACTIONS_RUNTIME_TOKEN==AUTH_KEY--artifact-server-pathflag == the directory you createdFor context I am running
acton Docker Desktop and Ubuntu on WSL2. I wasn't able to use the built in Golang server thatacthas and it's probably due to docker networking on WSL2.@Ngel-Castro commented on GitHub (Mar 25, 2024):
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!
@pbabinca commented on GitHub (Oct 10, 2024):
re:
https://gitea.com/gitea/act_runner/issues/119 explains the issue with v4:
and it also suggests two solutions:
master, since the bug has been fixed after v4 but there hasn't been an release since then. This worked for me.Note: Gitea refers to
docker/build-push-action. I'm not sure howactions/upload-artifactrelates to that one.@zatarain commented on GitHub (Oct 13, 2024):
Kudos for @VitusAcabado and @davetapley! Thank you so much 😊 I spent quite few hours with this issue before tried your approach.
The approach they mentioned about running a Docker 🐳 container 📦 with artifact server worked for me in Windows (using PowerShell even without my WSL2 environment).
I just renamed the host to
artifacts.docker.internaland output folder../artifactsbecause I use act in multiple repositories within the same folder and I didn't want to add another pattern to.gitignorefile on each of those repositories.Then I added following lines to my
.actrc:So, I ran the container as follow:
Just out of curiosity, is this issue closed because the actual problem is in
actions/upload-artifact?@youtux commented on GitHub (Oct 27, 2024):
hi, why is this issue closed? I'm still getting the error about the variable
ACTIONS_RUNTIME_TOKENnot being present when trying to download an artifact:Is there a solution for this?
@ChristopherHX commented on GitHub (Oct 27, 2024):
This feature exists if you tell act where to put the files, but we both probably agree why the hell is this disabled by default.
artifact v2-v3 fullsupport, v4 with known issues
See
act --help--artifact-server-pathDefines the path where the artifact server stores uploads and retrieves downloads from. If not specified the artifact server will not start.Depending on the setup of docker communication issues exists for m-series macs.