Patching

Applying a patch

A Meteor package is a ZIP archive containing all of the required code files and a meteor.phar binary used to apply the patch.

Once a package has been uploaded and extracted on the server it can be applied using the patch:apply command.

cd package
php meteor.phar patch:apply

Meteor will now begin applying the patch to your installation using the default options.

View a recording of a patch being applied:

Rolling back a patch

If a patch went wrong and could not complete you can roll back to the latest backup (created by Meteor when patching) using the patch:rollback command.

The command should be run from within the package that needs to be rolled back.

cd package
php meteor.phar patch:rollback

View a recording of a patch being rolled back:

Meteor will find the most recent compatible backup then restore the backed up files and migrate down the database/file migrations. If there are multiple backups available to rollback to then Meteor will ask you to choose a backup. If the most recent backup is not selected then the intermediate backups will be removed after the rollback has completed.

After rolling back a release it is recommended to re-apply the patch for the current version. For example when rolling back from 1.2.0 to 1.0.0 then patch again with 1.0.0. The reason for doing so is to ensure that all of the files for 1.0.0 exist on the server. Some file migrations may have run that would delete files that no longer exist in the newer version and the backup would not contain those deleted files.

Skipping migrations

To apply or rollback a patch without executing migrations down the following two options are availabe, --skip-db-migrations and --skip-file-migrations.

php meteor.phar patch:apply --skip-db-migrations
php meteor.phar patch:rollback --skip-db-migrations

The --skip-db-migrations option would most commonly be used when patching load balanced environments where the migrations do not need to be run on every node.

php meteor.phar patch:apply --skip-file-migrations
php meteor.phar patch:rollback --skip-file-migrations

Skipping the package verification

php meteor.phar patch:apply --skip-verify

If at any time you want to just verify the package the following command can be used:

php meteor.phar patch:verify

Specifing a different log dir

php meteor.phar patch:apply --log-dir=/var/www/jadu/logs

The meteor log will be created in the specified directory if it exists

Limiting number of backups

If you want to limit the number of backups that are on an environment, you can pass on an optional --limit-backups parameter

php meteor.phar patch:apply --limit-backups=3

Configuration

{
    "patch": {
        "strategy": "overwrite",
        "replace_directories": [
            "/vendor"
        ]
    }
}

strategy (optional)

Defaults to: overwrite - files are copied from the package over the top of the same location in the install.

replace_directories (optional)

List of directories that should be removed from the install before the version in the package is copied in. This is useful for directories like /vendor, where the contents may change significantly between releases and tracking of any files to be removed is beyond your control.

Defaults to empty.

Guides

Documentation