Compare commits

..

No commits in common. "466efa95ef8d285a145d2d324e62a9c50de283b7" and "bdd27446eb08ba3cd5888e25003169229a1d9af3" have entirely different histories.

4 changed files with 8 additions and 83 deletions

View File

@ -1,66 +1,48 @@
all: debug
.PHONY: all
# Builds the debug release inside the Alpine container. For build caching, two
# volumes are used named `fej_build-cache` and `fej_registry-cache`. These
# images are automatically created for you if they don't exist. If you
# encounter any strange build errors, you can try removing this volumes to
# start a completely fresh build.
# Builds
debug:
@ ./build -m dev -a run build
.PHONY: debug
# Builds the release version. In contrary to the debug version, this build
# doesn't use volumes for caching, as this would require the build to happen
# during runtime instead of during the building of the image. Instead, it uses
# the new `--mount` feature from Buildkit. This does mean that only very recent
# Docker engines can build the release version (in my case, at the time of
# writing this, 20.10.5).
release:
@ ./build -m rel
.PHONY: release
# This builds the release version, and pushes all relevant tags to my Docker
# Hub repository, namely chewingbever/fej
push:
@ ./build -m rel -a push
.PHONY: push
# This builds the debug release, and runs it detached. The reason we detach the
# container is because Rocket has a tendency to ignore ctlr-c when inside a
# container, which gets annoying really fast.
# Run
run:
@ ./build -m dev -a run
.PHONY: run
# As a workaround, we just have a stop command that stops the container.
stop:
@ docker stop -t 2 fej
.PHONY: stop
# This attaches to the running container, essentially giving the same result as
# just running `cargo run` locally.
logs:
@ docker logs -f fej
.PHONY: logs
# Builds the debug version, and runs the tests (but doesn't detach).
# Testing
test:
@ ./build -m dev -a run -l -- test --no-fail-fast
.PHONY: test
# Runs the cargo code formatter on your code.
format:
@ cargo fmt
.PHONY: format
# Lints your code. This also gets run in the pre-commit hook, basically
# preventing you from committing badly-formatted code.
lint:
@ cargo fmt -- --check
.PHONY: lint
# This builds the documentation for the project, excluding the documentation.
# Documentation
docs:
@ cargo doc --no-deps
.PHONY: docs

View File

@ -24,23 +24,3 @@ Every module has a `routes` function that returns its route macros.
## Roadmap
See [roadmap.md](roadmap.md).
## Development
The entire toolchain runs on Alpine inside Docker. This makes building easier,
and (hopefully) eliminates any system-specific bugs.
A [Makefile wrapper](Makefile) is provided for ease of use. Do check it out, as
all the commands are documented for your understanding ;)
There's also the `build` script. This script does all the "heavy" lifting. It
chooses which Dockerfile to build according to the given arguments, and
generates tags for the images (useful when pushing releases). The Makefile is
really just a wrapper around this build script, allowing you to write
`make test` instead of `./build -m dev -a run test`.
tl;dr run `make run` to run your build, and `make test` to run the tests.
## Docker images
The images are available [here](https://hub.docker.com/r/chewingbever/fej).

View File

@ -4,7 +4,7 @@ This file contains a listing of my current ideas/plans for this project. This
could change at any minute, but it serves as a quick overview of my plans for
the project.
## Ivago
## 1.0: Ivago
### Summary
@ -30,7 +30,7 @@ still collecting the same data. Furthermore, having the data available in
computer-readable format opens up ways to write a custom frontend for the API
(which I will be doing sometime in the near future).
## The Curse of the Forge
## 2.0: The Curse of the Forge
### Summary
@ -65,12 +65,3 @@ touch their websites or services (besides downloading the mods of course).
As a bonus, I want to cache the Ivago API's calendars, considering I'll be
setting up a database for this version anyways.
## Kissanime
I like watching anime from time to time, and I've always used Kissanime for
this. However, their sites can be quite slow, and riddled with ads from time to
time. That's why I'd like to create a high-speed wrapper that extracts all the
needed info from their sites, removing the need for the user to ever actually
visit their site. The API can just act as a fast search index, complete with
indexing of the links to the videos and everything.

View File

@ -3,36 +3,8 @@ extern crate rocket;
use fej_lib::{catchers, ivago};
// Very temporary solution for CORS
// https://stackoverflow.com/questions/62412361/how-to-set-up-cors-or-options-for-rocket-rs
use rocket::fairing::{Fairing, Info, Kind};
use rocket::http::Header;
use rocket::{Request, Response};
pub struct CORS;
impl Fairing for CORS {
fn info(&self) -> Info {
Info {
name: "Add CORS headers to responses",
kind: Kind::Response,
}
}
fn on_response(&self, _: &Request, response: &mut Response) {
response.set_header(Header::new("Access-Control-Allow-Origin", "*"));
response.set_header(Header::new(
"Access-Control-Allow-Methods",
"POST, GET, PATCH, OPTIONS",
));
response.set_header(Header::new("Access-Control-Allow-Headers", "*"));
response.set_header(Header::new("Access-Control-Allow-Credentials", "true"));
}
}
fn rocket() -> rocket::Rocket {
rocket::ignite()
.attach(CORS)
.mount("/ivago", ivago::routes())
.register(catchers![catchers::not_found])
}