Git deploy files to custom filepath
in progress
Stian Hjulstad Nilsen
Several clients have expressed the need for greater flexibility in deploying Git repositories, specifically the ability to define a custom file path for deployment. The latest request from a partner emphasizes the importance of this feature:
* Define a custom file path for deployment
"It would be beneficial if we could specify a deploy point within the file system. For instance, we typically populate our repository one level above the 'public/' directory."
Currently, the Servebolt Git integration deploys all files directly into the 'public/' directory.
Log In
Thomas Audunhus | Acting CEO | Servebolt
in progress
Thomas Audunhus | Acting CEO | Servebolt
Thank you for posting, Stian Hjulstad Nilsen! I have a few more questions for you:
- Could you provide more details on the specific use cases where deploying Git to a custom filepath would be beneficial?
- Could you elaborate on the types of scripts you would like to run automatically after deployment?
- Are there any specific security considerations we should be aware of when implementing the ability to run a script automatically after deployment?
Stian Hjulstad Nilsen
Thomas Audunhus | Acting CEO | Servebolt
- Whenever git repositories are pulled, it's quite common to know exactly where the files will land. Currently, the Servebolt Admin Panel doesn't specify where the files will land whenever you use the git implementation. Here are some specific use cases where deploying Git to a custom filepath would be beneficial:
* Adding a custom filepath destination will allow the user to understand with certainty where the files will land
* The current git integration requires users to use Servebolt's default file/folder structure, which may not suit all projects. Allowing custom filepaths will enable pulling files into directories outside the ~/public/ folder, accommodating a wider range of project structures.
* Not all files should be publicly accessible
* (I believe) symlinks can be preserved if we allow for a custom filepath
* More flexibility
- Type of script to run after deployment: Bash/Shell script or commands. This could for example be a simple cache purge command
- Good question, here are some thoughts: We obviously don't want malicious code to be executed. Maybe we could:
* Enable proper logging for scripts executed
* Limit/restrict commands to be run, maybe we could create predetermined commands?
* Limit the functionality to a paid plan
* Long-reach.. But inspect and sanitize script before allowing an execution.