CIRepository Asset Restore

We've recently setup a new Xperience by Kentico project using both CI and CD. Currently we have the /assets folder included within the git repository however I don't think this is correct, as when a media item is uploaded a version is stored in both the "CIRepository" folder and the "assets" folder.

I've deleted my local "assets" folder however when running the CI restore command locally

dotnet run --no-build -- --kxp-ci-restore

I expected it to restore all the assets from the "CIRepository" folder back into a local "assets" folder, which is not in the .gitignore, however nothing happened, it restored all the DB changes as expected however nothing happened with the assets.

Searching the documentation and using the AI agent I received the following response

When you run a CI restore in Xperience by Kentico, the system restores all objects and content items from the CI repository, including any asset binaries that are referenced by content items and serialized next to their XML definitions in the CI repository folder.

For fields of the "Content item asset" data type, the referenced asset binary is stored next to the XML definition in the CI repository. During CI restore, these binaries are restored and made available to the application.

You do not need to manually copy files from the CI repository to the assets folder. The CI restore process handles restoring the necessary asset binaries for content items. However, if your project uses assets that are not referenced by content items (and thus not serialized in the CI repository), those assets would need to be provided separately.

Are you able to let me know what I'm doing wrong?

Thanks.

Tags:
CI/CD Content hub
1

Answers

I used AI to dig into the XbyK source code to figure out exactly what's happening here. I don't think you're doing anything wrong, I think there's a genuine gap in the CI restore behaviour.

The CI restore process does include logic to copy asset binaries from the CI repository into the assets folder, but it's guarded by a hash-based optimisation. Before restoring the binary, it checks CI_FileMetadata table to see whether the file has changed since the last restore. If the hash matches it gets skipped, even if the file doesn't exist in the destination assets folder.

When you're running the restore, it's checking the database and seeing "nothing has changed".

Based on this, you probably could run TRUNCATE TABLE CI_FileMetadata and then CI restore and it would probably work. I think if everything I have said is correct, really the CI restore command could be extended to have a --force or --reset-metadata flag which handles this process fully if you want to fully restore.

2

To response this discussion, you have to login first.