Replacing the way to send the wallpaper, logo, and zipfiles from the webapp to build server

[pranav1698]

I'm submitting a ... (check one with "x")

• bug report
• feature request
• support request => Please do not submit support requests here, instead ask your query in out Gitter channel at https://gitter.im/fossasia/meilix

Expected Behaviour
In the current build, wallpaper in stored in the wallpapers folder in the server and previously this was accessed during the build by accessing https://meilix-generator.herokuapp.com/. This can cause same wallpaper for two different users which have build the ISO using the generator.

Would you like to work on the issue?
Open

[xeon-zolt]

you are talking about race condition yes it can happen you can send wallpaper in the API as base64 and keep storing them in with a random name lets say we use uuid for that

[pranav1698]

I have tried the idea of sending the wallpaper to the API encoding with base64, that happens after #396 is merged, but I have not tested the wallpaper

[tabesin]

Please also keep @meets2tarun in the loop and let's experiment.

[pranav1698]

@tabesin @xeon-zolt I have tried sending the wallpaper as an encoded base64 string,
The problem is that the base64 strings will be so big for a large image that when this will be send to the server as an environment variable, it becomes an unbound variable and cannot be stored in bash script so the build gives a error.
The method would work for a smaller image (<500 KB) but it will not work for a bigger image,
We need different way to store these base64 encoded strings in the server or a different way to send the binary files

[xeon-zolt]

I have a plan

1. user will upload an image for wallpaper
2. then we upload it to transfer.sh
3. then we get a link from transfer.sh
4. then we send that link to Travis ci
5. Travis ci will download from transfer.sh
6. build iso using the downloaded wallpaper

[xeon-zolt]

[tabesin]

If you implement third party services for practical reasons also ensure that the mechanism works without that service. That is the basic proof of concept must be without such external dependencies. If they are added then in a way that you could disable them without coding.

[xeon-zolt]

I too have fear of being reliable on third-party service so we can do one thing can add multiple services like these and use try-except block so in case anyone is down other will be automatically be used