blset

blset

Hello,

it’s not clear what is the app dir with releases

I have files generated by the phoenix web app that can be downloaded.
They are stored in a directory called downs of the app dir. if I change release I expect these files to stay where they are and be found by all releases

I have added
plug Plug.Static, at: "/downs", from: Path.expand('./downs'), gzip: false
I then generate urls with /downs/xxx

1- if I run the app with mix phx.server from the app dir it works ok
2- if I run the app with _build/rel/prod/v1/bin/v1 start from the app dir (after having build the release) it works ok

the problem is :

3- if I upload the release previoulsy built (on another machine) to another directory test1 with the downs dir copied into test1 (but not in priv/static) , and from test1 I run v1/bin/v1 start, the app works ok but the files in downs are not found

I uploaded in test1 only the content of v1, not the full tree _build/prod/rel/v1

the url is correctly generated but looks like the plug static line is ignored in case 3

thanks for any advice

in short

> test1
> - downs
>    - file1
> - v2
>   - all files generated by mix release found under _build/prod/rel/v2 originally

file1 present when generating the release is found
but a file2 put by the application when running the release is not found for download although the url are exaclty similar

/downs/file1
/downs/file2

since file2 was put by the running application the app dir is ok but the download of the file intercepted by plug static works for file1 but not for file2

Showing Posts 1 to 8

blset

blset OP

according to a similar post Plug.Static is unable to serve files in production - #8 by OvermindDL1

this could be that the path for plug static is resolved at compile time

plug Plug.Static, at: “/downs”, from: Path.expand(‘./downs’)

so the . is the directory where the release was built, so when moving the release to another directory, it does not work anymore

but that does not explain why file1 is found and not file2

blset

blset OP

finally the answer from the doc of plug static

Plug.Static will be unable to serve assets if you build releases or if you change the current directory. Instead do:

plug Plug.Static, from: {:app_name, "priv/app/path"}
Kurisu

Kurisu

I guess the issue comes from Path.expand/1. As stated in its doc, it

converts the path to an absolute one and expands any . and .. characters and a leading ~

Given that fact, you could take advantage from some environment variable depending on wether the app is running in production, development…

plug Plug.Static,
    at: "/downs",
    from: System.get_env("MY_APP_DOWNS_PATH"),
    gzip: false

Note that with this MY_APP_DOWNS_PATH should match to a path on the machine where the releases will be run.

This won’t probabbly be what you want. So config/releases would serve you better.

Edit: MY_APP_DOWNS_PATH in my example is of course an absolute path and can even be outside the app folder.

I see you’ve already found a solution that works for you. ^^
I was assuming that your downs folder is not a classic “assets” folder files and shouldn’t be renewed from release to release.

kokolegorille

kokolegorille

Another reliable way is to use a path relative to

:code.priv_dir(:your_app)
blset

blset OP

indeed downs is not a classic assets folder it is a folder in some enclosing dir that is


- maindir
    - downs
    - rel1
    - rel2
    - further releases

and I run

rel1/bin/app start

form the maindir or

rel2/bin/app start

according to the release I want to start

the solution I have found is to use first

plug Plug.Static, at: “/downs”, from: {:app_name, “/downs”}, gzip: false

and then put manually a symlink to the real downs in the app dir which is something like

rel1/lib/app_name-vsn

I have tried to put the symlink when generating the release but I have difficulty copying it to the remote folder

Kurisu

Kurisu

So I would do something like:

plug Plug.Static,
    at: "/downs",
    from: Application.get_env(:my_app, :downs_path) || Path.expand('./downs'),
    gzip: false

Then in config/releases.exs

import Config
config :my_app, :down_path, System.fetch_env!("DOWNS_PATH")

And I will create on the production machine the Environment variable that will be fetched each time I start a release:

export DOWNS_PATH="/home/prod/maindir/downs"

I did something similar for an umbrella project which children apps share a downloads folder outside the releases folder.

Hope this will be helpfull.

blset

blset OP

That works well thank you very much for help

blset

blset OP

I thought it worked but in fact that does not work because at compile time

Application.get_env(:my_app, :downs_path) || Path.expand(’./downs’),

Application.get_env returns nil so you get the path of the machine which builds the release not the runtime path

I ended up with

plug Plug.Static, at: “/downs”, from: {:vf, “../../../downs”},

that is a relative path which saves the need for the ENV var

— All posts loaded —

Where Next? Top

Trending in Questions Top

RSP87
I’m working on a project that simulates the bumbl example in the programming phoenix book. It acts almost like an email client. We have a...
New
kszambelanczyk
Hello! Could someone please give me a help/sample code, how to delete a file from s3 using waffle/waffle_ecto from Phoenix app. I creat...
New
RemyXRenard
I’m seeing that a list inside a Kino.DataTable will be interpreted as a charlist, even if the Kino.configure() is set to charlists: :as_l...
New
velrest
So my question is quite simple and i have found no conclusive answer on forum, google or AI. Should we use :erlang.float for Integer to ...
New
samoloth
Hi, I’ve just set up an application with ash_authentication. There is only magic link strategy for now, so there is no confirmation add o...
New
FlyingNoodle
If a change or preparation module uses Ash.Changeset.get_argument/2 or Ash.Query.get_argument/2 (or any of the other get_argument functio...
New
ryanwinchester
apply_graft/2 doesn’t rewrite an add_many sub-workflow’s deps on an add step. Grafted jobs cancel with “upstream job was deleted” Version...
New

Other Trending Topics Top

mudasobwa
I am happy to introduce the very α version of the new programming language compiled to BEAM. Welcome Cure. It has literally three kille...
New
garrison
Hobbes is a low-level distributed database for the Elixir programming language. Hobbes provides a simple, safe, and scalable storage lay...
New
marciok
Hi there! We created Gust: A task orchestrator inspired by Airflow. For those who have never heard about Aiflow, it’s a Python-based wor...
New
jimsynz
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Dmk
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
New
Damirados
Hello everyone. After busy few months I am happy to announce v0.1.0 of Emerge & Solve. They are GUI (Emerge) and State management (S...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews