You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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?
The text was updated successfully, but these errors were encountered:
@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.
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.
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 theexpath-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
npm run build
to build tuttle10000.0.0
, to be safe.npm run build
againautodeploy
folderautodeploy
folderContext (please always complete the following information)
Additional context
I am setting up a (stack of) docker layers to:
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?
The text was updated successfully, but these errors were encountered: