Closed link2xt closed 1 year ago
assets directory is built once and is not changed.
what does this mean? built by who? when you first run the binary/CLI ??
assets directory is built once and is not changed.
what does this mean? built by who? when you first run the binary/CLI ??
assets/
directory is created when you run pnpm run build
in the frontend
directory and goes into dist.
This is the current distribution contents:
xdcstore/
xdcstore/xdcstore
xdcstore/assets/
xdcstore/assets/store.xdc
xdcstore/assets/submit-helper.xdc
xdcstore/assets/review-helper.xdc
When you run the bot, it will not store anything in assets/
directory, you can even make it read-only.
if I got this correctly, sadly this is not improving the deployment at all more the other way around, why not to use the assets
folder relative to the CLI binary location for now? that will already made really easy to replace one release with another without the symbolic link tricks I am using right now
if I got this correctly, sadly this is not improving the deployment at all more the other way around
To switch from one release to another you can remove the whole distribution, keep the .config
directory and simply restart the bot. You do not need to import xdcs each time anymore. Isn't it an improvement?
For example, to run this PR, if you already had the bot configured in ~/.config/xdcstore
, you need to run:
wget https://download.delta.chat/store/preview/xdcstore-117.tar.gz
tar xf xdcstore-117.tar.gz
cd xdcstore
./xdcstore start
why not to use the assets folder relative to the CLI binary location for now?
I am not aware of any application looking for its data relative to the binary. Is there any problem starting the binary from the folder where you unpacked assets/
?
that will already made really easy to replace one release with another without the symbolic link tricks I am using right now
I don't know which symbolic links trick you are using. To switch from one release to another with this PR all you need is to unpack the distribution tarball, switch to xdcstore
directory and run ./xdstore
from there.
I am not aware of any application looking for its data relative to the binary. Is there any problem starting the binary from the folder where you unpacked
assets/
?
I am not aware of an app taking its private static data from current working directory either, ideally it would have it inside the binary, but as that is mentioned to be out of the scope of this PR, it is better to have the folder next to the binary as a temporary solution than needing it to be in the current working directory, the distribution already have the binary and the assets folder in the same folder as a portable program, thinking about installation in /usr/local/bin etc is out of the scope now and only extra work if after downloading the portable tarball you have to move folders around manually without an installation script etc
You don't need to move any folders around, just tar xf ...; cd xdcstore; ./xdcstore start
. Is there any problem with changing the directory to the binary directory before running it? Why symlinks are needed?
yeah having to change cwd every time is annoying I prefer to do a symbolic link then, but in any case is nicer if someone deploying can just run the binary without having to worry about such detail
what is the advantage of having to change to the bin directory over just picking the stuff directly?
I made a follow-up PR to look for assets/ relative to the binary: #119.
Would be nice to also update the gitignore (do some cleaup aswell) so assets is not added to version control
Frontend xdcs are now stored in
./assets/
, assets directory is built once and is not changed. Moving this to something like/usr/share/xdcstore
or building into the binary is out of scope for this PR.Both databases (bot database and deltachat core database), blob storage and imported XDCs folder
xdcs/
go to~/.config/xdcstore
. Removing~/.config/xdcstore
resets the bot.Closes #93