#Sitecorehub

Sitecorehub is a lightweight management UI to centralize and make building sitecore/docker-images simpler, visual and more intuitive than the current process. For those familiar with the existing project, it is to replace some aspects of the current build pipeline and at its core act as a replacement for the Assets image via a Web API. Streaming from a blob/API reduces the need for creating a large assets image locally while preserving the same reduction in layers.

As of right now, the code will load all 9.x asset files and display the depedencies per version, along with indicating if they exist in the blob container:

They also filter per version, and images that exist in the blob:

The blobs were uploaded manually (see known limitations section).

While cross-platform, documentation assumes any depedencies (such as Azurite) are installed and accessd via Linux, e.g., 0.0.0.0/localhost resolves correctly and Linux style directory structure. The project itself is intentionally agnostic and cross-platform. Ironically, as a tool for a build process, the build process for the build process tool works well given the prerequisites and can be improved upon later.

Currently only supported release as .NET Core is deprecated as of 12/23/2019. See here to install .NET Core 3.1

Due to the early release nature of the project, it relies on the Visual Studio "container fast mode". This invokes Visual Studio targets based off of preferences for Linux distribution set in Windows Deskto for Docker. This is not a hard dependency it runs just fine without having use the Dockerfile. The project itself is intentionally cross-platform and OS agnostic once built.

For local blob emulation. I created a persistent volume in ProgramData/azurite, running in blob only mode

mkdirk /mnt/c/programdata/azurite

docker run -p 10000:10000 -v /mnt/c/programdata/azurite:/workspace mcr.microsoft.com/azure-storage/azurite azurite-blob --blobHost 0.0.0.0

I highly recommend Azure Storage Explorer and testing the connection using the default connectionstring in the appsettings.json.

• To download the files from Sitecore, credentials are needed. These are usually set in the Azure KeyVault, but there's no way to emulate requests to a Azure KeyVault with Azure Functions. Per the latest documentation azure-functions-host issue #3907, suggests using seaparate code paths (e.g., Environment.GetEnvironmentVariable("WEBSITE_INSTANCE_ID, see here. This is something I am specifically trying to avoid, multiple codepaths for multiple environments. I will be looking at this as a viable option, though I'm obviously not wanting to continuously add non-MSFT approved emulation for local development.
• Working WebAPI similar to the asset image without needing to build it locally (streaming through an HTTP request vs mounting an assets image has same impact on Docker layers). Moves downloading/extracting/generating a large amount files just for local development.
• Generate csproj files for all microservices using hosting startup assemblies in ASP.NET Core. Right now adding a plugin to the Sitecore engine is the reverse of what it should be. It involves editing deps json instead of adding a reference to a plugin and the json being generated automatically by msbuild. This requires you to update all SQL connections/config settings by hand. If this works a side effect would be easier to read DockerFiles as you're generating a real csproj.
• The assets image correctly takes non-scwdp zip files and extracts them. Blob storage does not allow compression/deprecompression in situ. An Azure Function must be run to decompress the files using an upload pipeline, but requires AddBatchFiles functionality. This is not currently supported by the emulator but on the Azurite roadmap. If WSL2 is to be a requirement, the simplest solution is unzip in a local folder, overcoming Windows file length restrictions (if you unzip in anything other then something close to your root, the path name is too long on Windows). Since EXT4 is being called directly in WSL2 the max path length of 4096 bytes should not be an issue, but I do not how and if this works. There's huge performance issues depending on how the operation is called, see wsl issue #4197. Unsure how the IIS context runs, despite being a Linux project, if it is hitting EXT4 directly or through /mnt/c/.
• Adding support for .update (TDS) files in Azure Toolbox. Some thid-party or internal parties, not OSS but proprietary, provide .update files which Sitecore Azure toolbox will not convert to a bacpac. Despite online documentation stating otherwise the module comments specifically states .update files will only convert scwdp files, not item files. There is however, in the decompiled source to the toolbox that generates a sproc for the update files which in turn can generate a bacpac. I would like to add this ability to the project, relies on decompiled code.
• Adding rudimentary checking a non-Sitecore package is compatible with the version of Sitecore. Again, I dealt with vendors/internal teams which provide packages or VS Solutions that are said to work against a certain version but do not. Currently the docker-image project will take any additional packages and blindly install them, which does work if the files are provided correctly, such as the order of operation on installation does not and should not matter. Since files can be delivered in a variety of manner I developed a tool that takes a package, .update, scwdp or solution/csproj and attempts to convert into a nuget package similar to Reverse Package Search, but based on the final build output of whatever Sitecore version you're targeting. An easy way to check if someone has Sitecore 7.5 installed, did a bunch of binding redirects and manual dll copies and delivered you a bad package.