I receive this error when trying deploy a very simple Deno app:
~/C/p/aye-aye flyctl deploy
==> Verifying app config
--> Verified app config
==> Building image
==> Building image with Buildpacks
--> docker host: 20.10.12 linux aarch64
latest: Pulling from flyio/builder
Digest: sha256:f5f5409044fa794081b1eb481b826b84201440cea1b0adbddd81a0e431d18e86
Status: Image is up to date for flyio/builder:latest
bionic: Pulling from flyio/buildpack-stack-run
Digest: sha256:f124ecbe27ec9482bbd80a7cbe1537e7ee26bb56cda59c9becf9403f956c495c
Status: Image is up to date for flyio/buildpack-stack-run:bionic
===> DETECTING
[detector] io.fly.deno 0.0.3
===> ANALYZING
[analyzer] Previous image with name "registry.fly.io/aye-aye:cache" not found
===> RESTORING
===> BUILDING
[builder] ---> Deno Buildpack
[builder] ---> Downloading and extracting Deno
[builder] https://deno.land/x/install/install.sh
[builder]
[builder] curl: (22) The requested URL returned error: 404
[builder] ERROR: failed to build: exit status 22
Error failed to fetch an image or build from source: executing lifecycle. This may be the result of using an untrusted builder: failed with status code: 7
The Buildpack would be nice, but other confused souls can use a simple Dockerfile like this:
FROM denoland/deno:1.19.0
# The port that your application listens to.
EXPOSE 80
EXPOSE 443
WORKDIR /
# Prefer not to run as root.
USER deno
# # Cache the dependencies as a layer (the following two steps are re-run only when deps.ts is modified).
# # Ideally cache deps.ts will download and compile _all_ external files used in main.ts.
# COPY deps.ts .
# RUN deno cache deps.ts
# These steps will be re-run upon each file change in your working directory:
ADD . .
# Compile the main app so that it doesn't need to be compiled each startup/entry.
RUN deno cache server.ts
CMD ["run", "--watch", "--allow-net", "--allow-read", "./server.ts"]
Well, Fly’s all-in on Elixir+Phoenix at this point, much to my chagrin (: Although, it is to be expected that they’d choose integrate really well with fewer technology stacks, and not look to boil the ocean, as it were (at least not until they cross the chasm, I guess).
The current fly launch for Deno should drop a working Dockerfile in place. We had an old buildpack-based deploy which you shouldn’t use anymore. This is what the docs are referring to.
@Taylor What does the build section of your fly.toml look like?
We tried to be all in on Deno first, but never could figure out a way to collaborate with them. They’re happier giving a bunch of money to Google.
But you’re right. We’ve learned it takes about 3 people to support a given framework. We’re branching out soon, though, but probably not to your first guess. Maybe your fifth guess?
No OP, but outdated sounds good to me, since it is always nice to be able to refer to the doc you once looked at (as a frame of reference to the newer one), than have it disappear altogether.