#59

WIP

• Add initial Dockerfile + .dockerignore
• Add documentation for docker compose
• Updated docker-compose to V2 variant docker compose
• CI through docker compose (untested)
• CI push docker image to dockerhub on release (untested)

BREAKING CHANGES

1. Removed vichuploader + knpgaufrette to use flysystem

2. The user can now configure the storage spaces (adapters) for his backups from the dashboard. It can currently configure a local adapter, or for S3 (AWS, Scaleway, ...) For each database, he can choose which adapter to use.

See #51

• Command to manually switch to local storage mode
• Command to manually switch to AWS S3 storage mode
• Storage type initialization at installation

• Taskfile: user docker compose plugin instead of docker-compose
• Upgrade Symfony to 6.1.5 & other vendors
• Fix code style after php-cs-fixer upgrade
• Fix code & tests after EasyAdmin upgrade

Request

Currently database backups are created directly on request, which is blocking. Instead it could be handled more gracefully by using Messenger. So instead of directly creating a backup on the button click, we'll dispatch a message containing the information needed to create the backup (e.g. a Database entity), and then let the worker handle that job.

Additional information

• This would require symfony/messenger to be added in composer.
• An additional environment variable MESSENGER_TRANSPORT_DSN to be set by the user.
• Additional information / links need to be supplied in docs on how to set up the workers to execute the jobs.

Hey @bastien70 & @jmsche 👋

I like the idea and setup of this bundle, so I would like to know if you are open to having a docker image for it? Even though I'm kind of new to making images myself, I've already started working on it, so if you are interested I'd love to create a PR and hear your feedback.

See #64

From now on, each user can access the databases and backups of any other user.

Moreover, there is no logic in the databases created being relative to each user since the application is supposed to help companies (and/or freelancers) to manage their databases, so you might as well centralize everything.

Perhaps users would like one database to be backed up every week, and another every day or month.

Currently, the user himself configures a single CRON task with a certain periodicity which will be the same for all databases.

Instead, we could indicate to the user to configure a CRON task which will be executed every day and which will check if there are databases to backup, according to the requested periodicity.

Problem

The max backups option does not remove the oldest backups when it reaches it specified value, but it removes the most recently created one.

Reproduce

1. Create a database and set max backups to for example 5.
2. Make 5 manual backups and check if this is correctly inserted in the database.

3. Now make another backup (nr. 6) and check the database again.

No new backup seems to be created and the same backups are still present.

Now, if you set the max backups option for the database to 6, and then create a new backup, the following happens:

It inserted a new backup, but with ID 7.

Conclusion

Apparently the check with max backups is done in the clean method, which is the root problem of this issue. The implementation with the looping over the backups is incorrect, as it causes the removal of the most recent backup right after creation, which explains the initially strange jump in ID after increasing max backups option.

Possible solution

Adding a method to the BackupRepository with custom querybuilder for selecting the backups to be removed, and then delete them in the current clean method. Or maybe doctrine collection matching could come in handy here. Many different solutions possible.

See #75

I updated CI to use mariadb from the docker-compose.test instead of a fresh mysql service. In this way, it allows me not to have to duplicate the procedure carried out in the docker-compose (which here forced me to create a test database and import SQL into it)

Also, I updated the used version of Ubuntu to the latest one. If that's a problem, I'll do that in a separate PR.

Request

Flysystem is a popular and actively maintained library (in contrast to Gaufrette), and is also being used in SymfonyCasts tutorials. I think making the switch to Flysystem is not a drastic change and it would probably be more attractive for other potential/future users.

Additional information

• OneupFlysystemBundle for integration with Symfony