Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Packages between environments get mixed up because of loose package-version-control #262

Open
sebastian-marinescu opened this issue Mar 13, 2019 · 3 comments

Comments

@sebastian-marinescu
Copy link
Contributor

sebastian-marinescu commented Mar 13, 2019

Summary

I'm using Gitify for handling environments and also new setups (by cloning/copying an old project).

Now when pushing to my production-environment it might install other versions of packages than used before, because let's say FormIt just released an update.

My "Gitify-process" on initial setup in an environment looks like this:

  1. Gitify modx:install
  2. Gitify package:install --all
  3. Gitify build --force --no-backup

In step 2. there are new updates to packages and new settings/plugins/snippets get installed to the DB.
Also already gitified snippets, like lets say "ImagePlus", get updates.
In step 3. my gitified old snippets (and other stuff) overwrite the newly ones. And also new stuff gets killed, because it's not gitified yet.

Step to reproduce

  1. Gitify modx:install
  2. Gitify package:install --all
  3. Gitify build --force --no-backup

Then in the packages grid, reinstall an extra you are sure got updated.

Observed behavior

Gitify extract and you see the "lost data" or new and not yet gitified data.

Expected behavior

Don't loose stuff in between environment setups, and be confident everything works as expected.

Possible solutions / ideas / additions to Gitify

  1. Gitify needs to be locked down on package-versions. That way installing on a new environment gives the user the exact versions used before. So the user should be able to provide an exact version in the gitify-config, like colorpicker-1.0.3-pl.
    The InstallPackageCommand needs to acknowledge this and get the specified version.
  2. A way of dumping currently installed package-versions back to the gitify-config. That way if the admin uses the MODX package-grid to reinstall/update packages, it can automatically be locked back to the config, something like Gitify package:dump --all or Gitify package:save --all.
  3. Maybe a new way of upgrading through Gitify, so already locked package-versions get installed and also dumped back to the gitify-config, something like Gitify package:upgrade --all.
  4. Maybe a way to force re-installation of packages, something like Gitify package:reinstall --all.

Current workaround

Currently when this happens, an admin has to manually hit the reinstall button in the MODX packages-grid, possibly on all packages, and then Gitify extract afterwards to have everything back in sync.

Related issues

#108 #56 #157 #83 #68 #4

@Mark-H
Copy link
Member

Mark-H commented Mar 13, 2019

I'd like to see 1, 2, 3 and 4 :p

@sebastian-marinescu
Copy link
Contributor Author

Yeah - me too :)
I'll start working on 1 or 4 asap, because I and @hugopeek really really need this for our magic-stuff.

@hugopeek
Copy link
Contributor

@sebastian-marinescu Another year flew by, but I may have found the answer to number 1. Some incorrect formatting when processing a request for an exact package signature lead to Gitify always using the backup method: looking for a partial match with a query.

Can you test the PR if it works in your scenarios too?

And btw, re-running package:install --all will also update packages if a newer version is available.. You still need to add newly installed packages in MODX to your .gitify manually, but at least you have the option to update them with 1 command.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants