-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
occ update:check
and occ app:update --all
don't match
#26203
Comments
|
Only difference I can see is:
While server/core/Command/App/Update.php Line 102 in 2a054e6
But there shouldn't be a difference unless you have apps in your server which you didn't install at all |
I don't understand. |
Yeah this was more technical information for other developers if someone has time to look at it. I just debugged it on my server and for me the assumption is correct. I had 2 apps not showing up in update:check (contacts and richdocuments) but both are disabled:
So yeah, it's a bit weird that app:update --all updates apps which are not enabled, but then again it could be the itention, because you can't enable the app right now unless you update it e.g. due to major upgrade with incompatibility. But from my POV server/lib/private/App/AppManager.php Lines 143 to 145 in d89a75b
Although we might need both methods |
This comment has been minimized.
This comment has been minimized.
@szaimen I had my scripts such that they do a app:update --all first, and then a update:check. I now swapped these and added some text delimiter so that I will see if the OP bug description happens again. And it did, on a 25.0.3 instance (release channel):
Same today, on an NC 26.0.0beta1 instance (beta channel):
Seems like the issue still exists. |
I just got the below output from the script that iterates through my instances and does
for each of them. The whole script runs approximately 10 seconds. Output abbreviated to such instances that show different outputs.
Whereas In In In In So, what's the deal here? Running that script regularly interactively, I quite often experience that a certain app is seen and updated by some instances, and e.g. an hour later by others, and even another hour later by the rest of the instances. So both commands seem to have some local caching or a throttle that prevents them from actually asking the server. I think the issue is about that these mechanisms are not in sync for one instance in itself (and among multiple instances on one server). |
OR … ( I may have spoken too soon) … it's just an access issue on the apps.nextcloud.com loadbalancer or sorts: {"reqId":"BBvGCeJOW9OcsKtm0R2x","level":2,"time":"2023-02-21T22:16:48+01:00","remoteAddr":"","user":"--","app":"appstoreFetcher","method":"","url":"--","message":"Could not connect to appstore: cURL error 7: Failed to connect to apps.nextcloud.com port 443 after 23 ms: Couldn't connect to server (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://apps.nextcloud.com/api/v1/apps.json","userAgent":"--","version":"26.0.0.6","data":{"app":"appstoreFetcher"}} |
Learning about the I agree with some comments, that an ideal solution would provide some more context or options to either distinguish between active and disabled as well as compatible and incompatible apps or include/exclude them with an additional flag. |
occ update:check
and occ app:update --all
don't match
A lot of times
occ update:check
returnsand when I still run
occ app:update --all
afterwards I get do get updates.The entire shell looks like this:
or later the same day:
The text was updated successfully, but these errors were encountered: