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

Question, perhaps a bug: the autodeploy folder does not upgrade packages if the version is newer #5579

Open
DrRataplan opened this issue Dec 11, 2024 · 2 comments

Comments

@DrRataplan
Copy link

Describe the bug
I am trying to automatically redeploy a newer version of an installed app in a docker container. I expected that if I just update the version of the expath-pkg.xml, it would do so. The code at https://github.com/eXist-db/exist/blob/develop/exist-core/src/main/java/org/exist/repo/Deployment.java#L188 insinuates that the version will be compared, but alas, enforceDeps is false, so the version check is skipped.

Expected behavior
At first I expected a deploy to be done, as long as if the autodeploy folder contains a package with a version that exceeds the version that's currently installed. But then again, this could result into unexpected behaviour if the code is manually changed (ie. with eXide or whatever) and the database reboots.

To Reproduce

  • Get a clean ExistDB
  • Check out a package locally. In this example I'll use tuttle, but the actual package is irrelevant.
  • Run npm run build to build tuttle
  • Copy the xar to the autodeploy folder
  • Start exist and wait until everything is autodeployed
  • Verify the package is installed
  • Stop exist
  • Modify the package, at least change the version in its expath-pkg.xml (https://github.com/eeditiones/tuttle/blob/master/src/expath-pkg.xml#L3). Change it to 10000.0.0, to be safe.
  • Run npm run build again
  • Remove the old xar from the autodeploy folder
  • Add the new xar to the autodeploy folder
  • Start exist
  • Observe something along the lines of this in the logs:
#33 87.63 11 Dec 2024 13:26:50,178 [main] INFO  (Deployment.java [installAndDeploy]:192) - Application package http://e-editiones.org/tuttle already installed. Skipping.
  • The package is not redeployed.

Context (please always complete the following information)

  • Build: eXist-6.2.0 (c8fa495)
  • Java: 11.0.18 (Debian)
  • OS: Linux 6.11.0-9-generic (amd64)

Additional context

I am setting up a (stack of) docker layers to:

  • deploy some data,
  • deploy a version of the application code
  • transform the data using the application code (takes a long time)
  • push this to a registry
  • From there, on every commit of the codebase, generate a new docker container with the new codebase

There is no volume mounting needed because the data is read-only and easily reproducible from git repositories. The application code does change every so often, sometimes more often than the data. The data transformation needs some application code, but discussing that goes way outside the scope of this issue.

There is a workaround, I can undeploy and remove the installed package before moving over the new one in the autodeploy and restarting exist.

Is my expected behaviour correct?

@adamretter
Copy link
Contributor

@DrRataplan Unfortunately dependency management and versioning is not implemented properly in eXist-db's EXPath Repo code at the moment - so this could either be considered a bug or a feature request.

@line-o
Copy link
Member

line-o commented Dec 12, 2024

The question here is specifically about the AutoDeploymentTrigger, which has the fourth parameter (enforceDeps) of Deployment#installAndDeploy set to false (the exact line is linked in the issue).
Installing dependencies via PackageManager, XMLRPC or XQuery all do set enforceDeps to true last time I checked.

If we would set this to true for the AutoDeplymentTrigger we might end up installing packages

  • that were modified in the database and those modifications getting lost
  • that do not have proper SemVer versions in their expath-pkg.xml

I would consider this a configuration option. Especially interesting for instances that are built by automated processes for example, where control over package versions is key.
Then it would certainly be a feature.

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