Images disturbed

Hi all,

After gitlab upgrade to 14.4.1, some of the hashed images are migrated to wrong repositories

@hashed/00/12/ – original image location is stored in @hashed/12/34

please suggest if there is a way to identify the images

Perhaps you need to do this:

first, do this to find out what your local markdown version is:

curl -s --header "PRIVATE-TOKEN: your-api-token" | jq .local_markdown_version

install jq on your system if you don’t have this, since it will help filter out the other hundreds of settings so we can concentrate on the item we are after. On my system it reports zero because I haven’t needed to increase this value yet. The reason I ask you to check it’s current value is so that to invalidate the cache we want to increment the number. So, to increment:

curl -s --request PUT --header "PRIVATE-TOKEN: <your_access_token>" "<increased_number>"

replace <increased_number> so for me it would be:

curl --request PUT --header "PRIVATE-TOKEN: your-api-token" ""

since my value is 0 (zero), then I will increment to 1 (one). So you will do similar by incrementing your existing number by 1 (one)

This results nothing

If the api is working with correct api token, then it will return a result, a number. Mine gave 0 - so zero. Also you need to install jq if not already:

apt-get install jq

jq is already installed. How can we figure out the correct api token ? because in my profile its not activated and i can see just revoke option

Easiest way is in top right hand corner of web browser click your profile icon and preferences, then go to access tokens. Create a new one with api like my screen shot:

no need to give expiry date unless you want to. Then use the key generated in the curl examples I have, replacing with ip or fqdn of your server. You need read/write api to invalidate the markdown later when incrementing the number.

ok i have result as null so should i increase it ?

Yeah might be a good idea:

curl --request PUT --header "PRIVATE-TOKEN: your-api-token" ""

replace the api token and fqdn in the above command and it will increment. Then check it again with previous command to make sure it changed from null to 1.

ok i got too many settings like throttle_authenticated_files_api_enabled, “max_import_size”:50 and soon.

Then something is wrong with your api, since it should be working. I expect a lot of these problems are due to your upgrade issues from your other topic: E: Version for 'gitlab-ce' was not found - #5 by saga440

so not sure how you reverted your server, if you restored it from a Debian 8 backup as mentioned, or whether you tried repairing the existing installation without going back to a clean restore before the failed upgrade was attempted.

So obviously if the API didn’t run, then the value hasn’t changed and the problem with the images could still be because of this. Or the API updated the value, but didn’t help. In that case I’m not sure why, maybe someone else will help and add their thoughts to this topic, as I don’t know why it’s not working.

is there a way to fix the images pointing to the correct repositories right now most of the images are pointed to wrong repositories and to view the image we are moving manually to the correct repository. Please suggest

If the API command I gave you didn’t work, then I’ve no idea. Maybe someone from the Gitlab team will be able to assist.

apologize to hijack an old thread, but seems that topic is not resolved and I did encounter similar situation today, after upgrade to version 15.3.1. With this upgrade I have also updated the markdown plantuml renderer url, pointing to new location. Problem is, that already rendered md pages are still linking toward old url.

Already tried suggested api call in Invalidate Markdown Cache | GitLab. Strange thing is that


was set to 0 and I was able to set it to 1. But there was no observable result - already rendered markdown pages were still using old links.

Then I tried gitlab console, looking around some sample project if there is any information on markdown cache. It is inedeed - as i.e. in:

irb(main):035:0> project.cache_*

Interesting fact is - that i.e. cached markdown version here is much larger then local_markdown_version, i.e.:
irb(main):035:0> project.cached_markdown_version
=> 2031617

But from here on I have lack in knowledge and documentation if this ‘via console action’ is the right direction to clear the markdown cache.

Kindly ask for confirmation if this is the way to go and if there is any documentation on topic.