Deno Buildpack Broken

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

I’m suspicious that the Buildpack should be using https://cdn.deno.land/install/versions/v0.1.4/raw/install.sh instead.

1 Like

Also, all of the Deno docs are outdated:

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"]
1 Like

Btw, plenty deno.land Docker files are documented here: GitHub - denoland/deno_docker: Latest dockerfiles and images for Deno - alpine, centos, debian, ubuntu

Also, all of the Deno docs are outdated:

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).

1 Like

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. :slight_smile:

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?

1 Like

Out of curiosity, would labeling docs “outdated” be helpful to you? Or do you think we’re better off removing them entirely?

1 Like

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.