district09 / robo-digipolis-helpers Goto Github PK

test111111111111

Now only version up and including 6.x are supported.

As a follow-up to #6, the files option should be removed (where applicable) from the various backup methods. All other related functionality may be removed as well.

From @daften on March 29, 2017 10:13

So why symfony-scripts for symfony projects has to be done in the symfony package or with an overwritten Robofile. See also StadGent/symfony_site_checkjehuis#9

Copied from original issue: district09/robo-digipolis-deploy#8

@daften commented on Fri Jan 12 2018

We only need backups for previous versions of the site. So if there are 2 release folders kept, we only need 1 backup.

Maybe replace that with drush too? :s

To indicate what this project is for. It's basically the flow we use at Digipolis, but the README should indicate that.
Also some examples on how to overwrite this general flow in a specific project.

When that is done, maybe update general robo documentation with our approach?

So we can use the generic part in this package and add specific methods in framework specific packages.

digipolis:sync-local command uses readlink -e to read out the private key, but -e is unknown on MacOS version (BSD) of readlink.

Instead of tarring via the build server. To make sure large file directories can be synced too.

E.g. protected function syncTask(), public function digipolisSyncLocal()

New package name robo-digipolis-sync

[DigipolisGent\Deploy\Ssh] [email protected]:/home/data/apps/default/files$ tar -xkzf /home/data/apps/default/backups/1491296370/1491296370_2017_04_04_10_59_30.tar.gz
[DigipolisGent\Deploy\Ssh]
gzip: stdin: unexpected end of file
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now

[DigipolisGent\Deploy\Ssh] Could not execute cd -P /home/data/apps/default/files && tar -xkzf /home/data/apps/default/backups/1491296370/1491296370_2017_04_04_10_59_30.tar.gz on 10.25.2.151 on port 22 in folder /home/data/apps/default/files with message:
gzip: stdin: unexpected end of file
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
.

[DigipolisGent\Deploy\Ssh] Exit code 1
[error] Could not execute cd -P /home/data/apps/default/files && tar -xkzf /home/data/apps/default/backups/1491296370/1491296370_2017_04_04_10_59_30.tar.gz on 10.25.2.151 on port 22 in folder /home/data/apps/default/files with message:
gzip: stdin: unexpected end of file
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
.

Sometimes build tasks can take up quite some time. Ideally one should investigate why and optimize the task, but there are case where this cannot be done easily, for instance when something needs to get deployed "right away". But, there are also tasks that just take up some time, like backing up the files/ directory in projects that have a lot of files.

Seems that by making these time outs configurable (with sensible defaults, obviously) we can circumvent this on a per-project-base.

test

district09/robo-digipolis-deploy#11

When a build fails, depending on where it fails, it isn't cleaned up and sometimes a directory remains:

 [DigipolisGent\Deploy\Ssh] chmod: cannot access ‘vendor/bin/robo’: No such file or directory

As a consequence the next builds will fail as the output of the following command will return the remaining directory of the previously failed build:
ls -1 | sort -r | head 1

The following error will occur:

[DigipolisGent\Deploy\DatabaseBackup]  The configuration file "" could not be found. 

It might be missing, see district09/robo-digipolis-generic#2

When running digipolis:sync-local on MacOS the gunzipping of the db backup fails with error 'trailing garbage ignored'
When copying over the database backup manually from the server and then gunzipping it, this does not error.