vapor / template Goto Github PK
View Code? Open in Web Editor NEWUsed by Vapor Toolbox’s new project command
License: MIT License
Used by Vapor Toolbox’s new project command
License: MIT License
When following the hello world docs, you're prompted to use the name Hello
(note the uppercase "H") as the project title. However, the name is interpolated into the docker-compose file under the image:
key, and Docker image names can not include uppercase characters.
Steps to reproduce (using the latest version of Vapor):
$ vapor new Hello
$ cd Hello
$ docker-compose build
# ERROR: invalid reference format: repository name must be lowercase
A possible resolution would be to simply lowercase the name in the docker-compose file. I've done this manually and it seems to work - but I'm new to Vapor so I'm not sure if there are other implications. If this would work as a resolution, I'm happy to try and submit a PR.
If you create a new Vapor project with Leaf and no Fluent, then the project generates incorrectly.
$ vapor new test-project
Cloning template...
name: test-project
Would you like to use Fluent?
y/n> n
fluent: No
Would you like to use Leaf?
y/n> y
leaf: Yes
Generating project files
...
routes.swift
import Vapor
func routes(_ app: Application) throws {
app.get { req in
return req.view.render("index", ["title": "Hello Vapor!"])
}app.get { req in // this block shouldn't be here
return "It works!"
}
app.get("hello") { req -> String in
return "Hello, world!"
}
}
configure.swift (no app.views.use(.leaf)
)
import Leaf
import Vapor
// configures your application
public func configure(_ app: Application) throws {
// uncomment to serve files from /Public folder
// app.middleware.use(FileMiddleware(publicDirectory: app.directory.publicDirectory))
// register routes
try routes(app)
}
The project should compile after being generated, and should be setup correctly to use Leaf.
vapor: stable 18.3.3 (bottled), HEAD
xcode: 13.2.1 and 13.3 tested
macos: monterey 12.1
has existed for quite a while, only just raising it
Best to introduce a non-root user to the Dockerfile to execute the app.
Creating a new project from the template does not populate the Fluent Driver correctly.
Choosing Postgres when running new
vapor/toolbox, I expect:
.package(url: "https://github.com/vapor/fluent-postgres-driver.git", from: "2.0.0-beta")
but instead we get"
.package(url: "https://github.com/vapor/fluent--driver.git", from: "-beta")
Also reported in vapor/toolbox#279
Hello, when I create a new project with a mongoDB database, running docker-compose build
gives me the following error:
ERROR: Service 'app' depends on service 'db' which is undefined.
Here is the sequence of commands I used.
vapor new project-name
y (Fluent: yes)
4 (db: Mongo)
n (Leaf: no)
cd project-name/
docker-compose build
I don't know much about Docker, but I think the project should build "out of the box".
Maybe related to issue #31.
When the project doesn't have a Package.resolved
. Docker Desktop on Mac fails to build the project on Dockerfile line 20:
...
RUN swift package resolve --skip-update \
"$([ -f ./Package.resolved ] && echo "--force-resolved-versions" || true)"
...
This is the build log:
[+] Building 3.0s (14/22) docker:desktop-linux
=> [app internal] load .dockerignore 0.0s
=> => transferring context: 58B 0.0s
=> [app internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 3.26kB 0.0s
=> [app internal] load metadata for docker.io/library/swift:5.9-jammy-slim 2.6s
=> [app internal] load metadata for docker.io/library/swift:5.9-jammy 2.4s
=> [app build 1/12] FROM docker.io/library/swift:5.9-jammy@sha256:a13d1eff9d1639c967c2c1f28740328f57cde4caaf979d07e86811cbaefdd8 0.0s
=> [app internal] load build context 0.0s
=> => transferring context: 7.23kB 0.0s
=> [app stage-1 1/5] FROM docker.io/library/swift:5.9-jammy-slim@sha256:3beefe3ea2e54d49d11a4f9e54769268616e8ee5a26597dc0af15497c 0.0s
=> CACHED [app stage-1 2/5] RUN export DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true && apt-get -q update 0.0s
=> CACHED [app stage-1 3/5] RUN useradd --user-group --create-home --system --skel /dev/null --home-dir /app vapor 0.0s
=> CACHED [app stage-1 4/5] WORKDIR /app 0.0s
=> CACHED [app build 2/12] RUN export DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true && apt-get -q update 0.0s
=> CACHED [app build 3/12] WORKDIR /build 0.0s
=> CACHED [app build 4/12] COPY ./Package.* ./ 0.0s
=> ERROR [app build 5/12] RUN swift package resolve --skip-update "$([ -f ./Package.resolved ] && echo "--force-resolved-version 0.4s
------
> [app build 5/12] RUN swift package resolve --skip-update "$([ -f ./Package.resolved ] && echo "--force-resolved-versions" || true)":
0.357 error: dependency '' was not found
------
failed to solve: process "/bin/sh -c swift package resolve --skip-update \"$([ -f ./Package.resolved ] && echo \"--force-resolved-versions\" || true)\"" did not complete successfully: exit code: 1
Note that the build goes beyond line 20 when Dockerfile reverts to the parent of commit 6563d51, which has the following line instead.
...
RUN swift package resolve --skip-update
...
Steps to reproduce the behavior:
vapor new my-dockerized-app
and say no to everything when prompted.cd dockerized-app
docker-compose build
We should not see an error failing.
from: "4.83.1"
, can't give exact because Package.resolved
doesn't existAbout the Docker I'm using on the Mac:
Docker Desktop 4.24.0 (122432)
Engine: 24.0.6
Compose: v2.22.0-desktop.2
Credential Helper: v0.7.0
Kubernetes: v1.27.2
The Swift runtime dynamically loads libcurl4
and libxml2
for FoundationNetworking
and FoundationXML
, respectively — the --static-swift-stdlib
build option can't include those libraries in the binary so the runtime will crash at load, e.g:
./Run: error while loading shared libraries: libcurl.so.4: cannot open shared object file: No such file or directory
While a simple "hello world" Vapor app will work without libcurl4
and libxml2
, I don't think omitting them was deliberate. [Correction: It was deliberate.]. Rather, like omitting tzdata
(#75), this was probably an unintended side effect of changing the base run image to ubuntu:focal
in #61 instead of using a (heavier) official Swift "slim" image as the base (e.g. swift:5.6-focal-slim
).
For further reference:
Deps in the official Swift "slim" image:
https://github.com/apple/swift-docker/blob/a34976e/5.6/ubuntu/20.04/slim/Dockerfile#L5
Swift on Server: Packaging Applications for Deployment:
https://github.com/swift-server/guides/blob/main/docs/packaging.md
I'm having problems building the project.
Steps to reproduce the behavior:
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 3.90kB 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 58B 0.0s
=> [internal] load metadata for docker.io/library/swift:5.9-jammy-slim 0.8s
=> [internal] load metadata for docker.io/library/swift:5.9-jammy 0.7s
=> [build 1/12] FROM docker.io/library/swift:5.9-jammy@sha256:d1a20a7ca0272bc0313a443b313762e465bd657674e41fbd06a06740a389a84e 0.0s
=> [internal] load build context 0.1s
=> => transferring context: 71.90kB 0.1s
=> [stage-1 1/5] FROM docker.io/library/swift:5.9-jammy-slim@sha256:9809396932ec79fd891d3d7beb37c666b76bf9b4e3319142dcb5eed4b19629e0 0.0s
=> CACHED [build 2/12] RUN export DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true && apt-get -q update && apt-get -q dist-upgrade 0.0s
=> CACHED [build 3/12] WORKDIR /build 0.0s
=> CACHED [build 4/12] COPY ./Package.* ./ 0.0s
=> CACHED [build 5/12] RUN swift package resolve --skip-update $([ -f ./Package.resolved ] && echo "--force-resolved-versions" || true) 0.0s
=> CACHED [build 6/12] COPY . . 0.0s
=> CACHED [build 7/12] RUN swift build -c release --static-swift-stdlib -Xlinker -u -Xlinker _swift_backtrace_isThunkFunction 0.0s
=> CACHED [build 8/12] WORKDIR /staging 0.0s
=> ERROR [build 9/12] RUN cp "$(swift build --package-path /build -c release --show-bin-path)/App" ./
I still don’t understand what the problem could be
Last template of vapor for Docker
In considering vapor/vapor#2858, I wonder if a trivial async
example route should be added to the "bare" template?
Having both a non-async
and async
example would illustrate a fundamental concept of Vapor, and provide an easy reference when the usage intent is to spin up a new app with a single endpoint that needs to call an async
function. Vapor newcomers may also tend to generate using a "bare" template at the start of their learning (I know I did).
Or, the existing "It works!" and "Hello, world!" examples could be changed to use the async
form if that form is generally encouraged for new apps?
I put some thought into what a trivial additional async
example could be:
Task.sleep
for a couple secondsI like this option the most, followed by not doing any actual async
work (the first alternative below). Having an await
statement in the body of the function helps communicate the purpose of the example.
One drawback: a real app should never call Task.sleep
, so this could inadvertently suggest a bad practice.
// Sources/App/routes.swift
import Vapor
func routes(_ app: Application) throws {
app.get { req in
return "It works!"
}
app.get("hello") { req -> String in
return "Hello, world!"
}
app.get("async") { req async throws -> String in
let nanosecondsPerSec: UInt64 = 1_000_000_000
try await Task.sleep(nanoseconds: 2 * nanosecondsPerSec)
return "Hello, async style!"
}
}
Note: The global constant
NSEC_PER_SEC
is generally used to calculate a quantity of nanoseconds, but that's defined inlibdispatch
, which isn't really usable yet on non-Apple platforms (not that easily, at least). The nice time and duration APIs in Swift 5.7 will remove the need to calculate nanoseconds at all.
// Sources/App/routes.swift
import Vapor
func routes(_ app: Application) throws {
app.get { req in
return "It works!"
}
app.get("hello") { req -> String in
return "Hello, world!"
}
app.get("async") { req async throws -> String in
return "Hello, async style!"
}
}
This is still significantly differentiated from the non-async style "hello" function: it differs by the path segment, async throws
in the signature, and the return value. That differentiation doesn't illustrate purpose, tho.
// Sources/App/routes.swift
import Vapor
func routes(_ app: Application) throws {
app.get { req in
return "It works!"
}
app.get("hello") { req -> String in
return "Hello, world!"
}
app.get("async") { req async throws -> String in
let urlRequest = URLRequest(url: URL(string: "http://example.com")!)
let (data, response) = try await URLSession.shared.data(for: urlRequest)
if let httpResponse = response as? HTTPURLResponse,
httpResponse.statusCode != 200 {
return "Error while fetching data"
}
return String(decoding: data, as: UTF8.self)
}
}
A URL request is a familiar illustration, but this would depend on FoundationNetworking
on non-Apple platforms, additionally needing:
#if canImport(FoundationNetworking)
import FoundationNetworking
#endif
And, the default Dockerfile omits FoundationNetworking
's libcurl4
dependency to produce a smaller binary by default. The default Dockerfile should definitely successfully build the freshly generated app, and adding a heavy dependency to merely gain a usage example is a non-starter.
Making a real request to a hosted service in an app template can be inconsiderate to the host unless it's specifically meant for that kind of use. (I know example.com is meant for use in sample code, but I don't know whether it's meant for code that will actually be run.)
In some scenarios, good security policy may also block outgoing network traffic by default.
Lastly, the above URL request code doesn't compile on Swift 5.6 (I only tested linux). I didn't bother investigating why, but it seems the async
variation of URLSession.shared.data(for:)
was introduced in Swift 5.7, or perhaps the compiler's type inference just needs some helpful annotations. The example already isn't promising and isn't that trivial, and may be even more noisy once made to work on Swift 5.6.
Tests/LinuxMain.swift
is missing and newbies can't run just created app on Linux and don't know what to do 🙂
Observed: the template project code uses EventLoopFuture for concurrency.
Expected: now that modern concurrency is available, the template project should use async/await and showcase the simplified code.
I think this is only about the Todo (Fluent) app example routes and migrations.
See apple/swift-nio#2564.
This is not tagged as of creating this issue.
Running vapor new <project name>
generates boiler plates for a new project. It is a great starting point. However, it is surprising the boiler plate is missing a ReadMe file. It would be great to have one included in the initial project setup.
Hello,
after creating a new project with :
vapor-beta new todos
Wether or not we activate fluent
we cannot build using the command line nor Xcode.
The same error alway shows before starting any build :
manifest parse error: target 'App' depends on an unknown package 'Vapor'
I've been creating many project for the last weeks (recording a video course) and this seems to happen since commit 9ab71c0
I'm available if you need more testing.
I'm on Catalina with the Xcode 11.4 beta and Swift 5.2
Thanks
Trying to run the docker container results in an error where the app container doesn't actually start.
Steps to reproduce the behavior:
$ vapor new my-dockerized-app
$ cd my-dockerized-app
$ docker compose build
$ docker compose up app
Error:
Error response from daemon: unable to find user vapor: no matching entries in passwd file
Both the app and the database begin running. Currently only the database begins running.
Vapor template docker-compose.yml
contains directives that cause docker compose
to crash with a mysterious error.
vapor new template-app
to create an app from template. Use Fluent with Postgres, no Leaf.
cd template-app
docker compose up
After building, Docker crashes with some mysterious Go errors.
docker compose up
should build and run the containers.
The issue is caused by this piece of revert
and migrate
targets configuration in docker-compose.yml
:
deploy:
replicas: 0
When I comment these lines out, the containers do build and run, but I see blank non-running revert
and migrate
containers in my Docker Dashboard, which probably shouldn’t be like that.
Currently in the CI for testing the template we build the toolbox for each matrix variation. This is a bit wasteful and really we should build a statically linked toolbox in the first step and copy it to all the matrix options. This should cut down CI time
Currently any PRs don't have CI, we should fix this
We should add some CI to test PRs that does the following:
vapor new
for the various permutationsWe can base some of it on https://github.com/vapor/toolbox/blob/main/.github/workflows/test.yml#L8-L31
This could include a database setup depending on what (Fluent) Database driver is being used
Currently the template's Dockerfile compiles the application using dynamic linking and we copy that over to a slim image as we need the Swift runtime.
The current best practice (see https://github.com/swift-server/guides/blob/main/docs/packaging.md#docker) is to use static linking to improve start up times. This also means we can use a regular focal
image instead of the slim images, saving some size
And don't use slim images
Hello!
I hope you are doing well!
We are a security research team. Our tool automatically detected a vulnerability in this repository. We want to disclose it responsibly. GitHub has a feature called Private vulnerability reporting, which enables security research to privately disclose a vulnerability. Unfortunately, it is not enabled for this repository.
Can you enable it, so that we can report it?
Thanks in advance!
PS: you can read about how to enable private vulnerability reporting here: https://docs.github.com/en/code-security/security-advisories/repository-security-advisories/configuring-private-vulnerability-reporting-for-a-repository
I notice that when I create a fresh project while selecting sqlite as an option for db and run docker. The docker-compose won't build because db is not declared. Was something missing or need to be updated? Thanks
With DockerFile I'm unable to build with swift:5.7-jammy
and ubuntu:jammy
Output error:
clang-13: error: unable to execute command: Killed
clang-13: error: linker command failed due to signal (use -v to see invocation)
[975/976] Linking Run
The command '/bin/sh -c swift build -c release --static-swift-stdlib' returned a non-zero code: 1
Docker
I'm deploying to Google Cloud Build
support choosing whether Heroku or Docker support files should be included in a new project gen
When we get PRs for the template we should run some CI to ensure that things will work. This will involve running vapor new
on the the branch/fork of the template too ensure the syntax is right and then building it.
We should build it using the generated Dockerfile to ensure that works as well
Is your feature request related to a problem?
It would be helpful to have a way to search for Vapor Templates.
For example: search "topic:template topic:vapor"
It would also be helpful if topic:vapor-4
were also added to differentiate current from legacy template.
Describe the solution you'd like
I would like to see topics vapor
, vapor-4
, and template
added to the following repositories:
Thank you.
When running vapor new...
the Public
directory is not included in the final generated project, it should be.
We probably just need to add the directory to the manifest.yml file
Using docker buildx build
to cross-compile an amd64 image on an Apple Silicon Mac triggers a QEMU illegal instruction error during the swift package resolve
step in the Dockerfile.
This seems to be related to this issue in Swift and this issue in Docker Desktop for Mac. Those issues are both closed, and yet the illegal instruction still occurs when building a Vapor project under Docker Desktop 4.16.2 for Mac.
On an Apple Silicon Mac running Docker Desktop 4.16.2:
vapor new buildx-test
. You do not need fluent or leaf.docker buildx build --no-cache --platform linux/amd64 .
The build fails with this output:
docker buildx build --no-cache --platform linux/amd64 .
[+] Building 269.9s (15/24)
=> [internal] load .dockerignore 0.0s
=> => transferring context: 58B 0.0s
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 2.78kB 0.0s
=> [internal] load metadata for docker.io/library/ubuntu:jammy 1.8s
=> [internal] load metadata for docker.io/library/swift:5.7-jammy 1.8s
=> [auth] library/ubuntu:pull token for registry-1.docker.io 0.0s
=> [auth] library/swift:pull token for registry-1.docker.io 0.0s
=> CACHED [build 1/12] FROM docker.io/library/swift:5.7-jammy@sha256:e1da6de0a96b09438cfff68e7ab757eca073102fb34b5eaa637249545 0.0s
=> => resolve docker.io/library/swift:5.7-jammy@sha256:e1da6de0a96b09438cfff68e7ab757eca073102fb34b5eaa63724954536e9897 0.0s
=> [internal] load build context 0.0s
=> => transferring context: 40.24kB 0.0s
=> [stage-1 1/5] FROM docker.io/library/ubuntu:jammy@sha256:9a0bdde4188b896a372804be2384015e90e3f84906b750c1a53539b585fbbe7f 0.0s
=> => resolve docker.io/library/ubuntu:jammy@sha256:9a0bdde4188b896a372804be2384015e90e3f84906b750c1a53539b585fbbe7f 0.0s
=> [build 2/12] RUN export DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true && apt-get -q update && ap 38.9s
=> [build 3/12] WORKDIR /build 0.0s
=> [build 4/12] COPY ./Package.* ./ 0.0s
=> [build 5/12] RUN swift package resolve 198.2s
=> [build 6/12] COPY . . 0.0s
=> ERROR [build 7/12] RUN swift build -c release --static-swift-stdlib 30.8s
------
> [build 7/12] RUN swift build -c release --static-swift-stdlib:
#0 13.67 error: 'swift-algorithms': Invalid manifest
#0 13.67 qemu: uncaught target signal 4 (Illegal instruction) - core dumped
------
WARNING: No output specified with docker-container driver. Build result will only remain in the build cache. To push result image into registry use --push or to load image into docker use --load
WARNING: failed to get git remote url: fatal: No remote configured to list refs from.
Dockerfile:26
--------------------
24 |
25 | # Build everything, with optimizations
26 | >>> RUN swift build -c release --static-swift-stdlib
27 |
28 | # Switch to the staging area
--------------------
ERROR: failed to solve: process "/dev/.buildkit_qemu_emulator /bin/sh -c swift build -c release --static-swift-stdlib" did not complete successfully: exit code: 1
The docker buildx build
command should produce a cross-platform image without error.
I have had some luck getting builds to work by inserting QEMU_CPU=max
into the RUN swift
commands in the Dockerfile and by prefixing my docker buildx build
command with this environment variable. However, the results are inconsistent, and I'm having trouble narrowing down exactly where this environment variable is needed to produce reliable builds.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.