I posted this earlier and still haven’t solved it, I’ve deleted my old builder and got a new one, nothing works. As of now I still have to run fly deploy --remote-only on my local machine for it to work. This makes no sense and is very frustrating.
current log: Dockerfile · GitHub
previous thread: Anyone know why my GH actions build keeps failing (yarn)
I use the same github action config for a project in python and it works with 0 issues. Help?
I’ve ran the same install commands on Windows, Ubuntu, and MacOS so far and they all work, no issues, similar output. I feel like theres something really obvious im missing but i keep comparing the log files and theres nothing different, except for the sudden failure
edit: I got it to work by removing the remote-only flag funny enough. Which would be fine, but now I use 8 billable minutes instead of 2-3. Anyone have an idea why the remote won’t work? This is a newly provisioned builder
A remote build relies upon the entire build context being sent to Fly first, and then the build runs on the build machine. If remote building does not work from GitHub Actions but does work for you when you trigger the remote build from your machine, that would suggest that for some reason some of the necessary build context is not making it from GitHub Actions to Fly.
If I had to guess what the cause is, I’d guess that your application relies upon some file(s) that you have locally – and are therefore being sent to Fly’s builder when you launch a remote build locally – but those file(s) don’t exist in GitHub, so they are not included in the build context sent to Fly from GitHub Actions.
An issue like this is quite common if you have, for example, a local node_modules directory that has drifted from your package manifest, or some part of the build process is being skipped by yarn because it finds an already built asset. You can debug this by cloning your repository to a brand new directory on your local machine and then trigger a remote Fly build without building it locally first to ensure that the build context received by Fly from your machine is the same build context received by Fly from GitHub Actions. You can then run a build locally from the same directory, and you should see the same failure.
As a tip to avoid this in the future (if this turns out to be the problem!) there’s a very helpful approach to managing Docker build context: invert the way that you use .dockerignore so that everything is ignored by default and only files that you explicitly want to be a part of the build context are included. For example, picking a random js project of my own – here’s the .dockerignore:
*
!public/
!src/
!index.html
!package.json
!package-lock.json
!postcss.config.js
!README.md
!tailwind.config.js
!tsconfig.json
!vite.config.ts
This means that any build (local or remote!) will only receive the exact build context I expect to be received: if I have a node_modules directory locally, it will not make it to Docker’s build context, guaranteeing that every build is fresh and consistency across the different environments that can trigger builds.
the deploy using remote-only works only if I run yarn locally first. I don’t know why that is, node_modules is an ignored directory. I give up, ill just use what works.
Thank you for the dockerignore tip though
Suggestion: do the same within your github actions. Add two steps. One to setup node. One to run yarn. See: GitHub Action for Yarn · Actions · GitHub Marketplace · GitHub
Nice! That works, it’s just strange that its needed
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.