Repository navigation
Conversation
The image contains the OpenHarmony SDK/NDK, static OpenSSL 3.3.1 and ICU 75.1 built with the aarch64-linux-ohos toolchain, and the toolchain wrappers. It mirrors the recipe validated in dotnet/runtime#136206 and is the prerequisite for the official runtime-community leg (dotnet-buildtools-prereqs-docker#1778).
|
This is the OpenHarmony cross-compilation image used by dotnet/runtime#136206. The PR pipeline is green, including the OpenHarmony image build, Post_Build, and Publish. The image contains the OpenHarmony Public SDK 6.0.0.47 (API 20) under Apache-2.0, with SDK/OpenSSL/ICU notices preserved. It does not contain the Huawei HarmonyOS SDK, Apple SDK, or Android SDK. Could a reviewer from @dotnet/runtime-infrastructure or @dotnet/dotnet-docker-reviewers take a look?
|
|
@akoeplinger @dkurepa @mthalman — could one of you take a look at this image PR, or assign the right owner? It is the only remaining dependency for the OpenHarmony runtime-community leg in dotnet/runtime#136206. CI is green after the main merge. The change is one new If neither of you owns this area, could you point me to the reviewer who does?
|
| FROM mcr.microsoft.com/dotnet-buildtools/prereqs:azurelinux-4.0-net12.0-crossdeps-llvm-amd64 | ||
|
|
||
| LABEL org.opencontainers.image.title="OpenHarmony cross-compilation image" \ | ||
| org.opencontainers.image.version="6.0.0.47" \ |
There was a problem hiding this comment.
according to the build-ohos.sh script this just downloads https://repo.huaweicloud.com/openharmony/os/6.0-Release/ohos-sdk-windows_linux-public.tar.gz i.e. it doesn't pin the exact 6.0.0.47 version.
is that URL guaranteed to be stable or could it change (invalidating the sha hash)? if it is stable then I think I'd prefer just referring to 6.0 everywhere.
I also saw that https://repo.huaweicloud.com/openharmony/os/ lists 7.0-Release, any reason why we're not using the newest sdk?
There was a problem hiding this comment.
The 6.0.0.47 / API 20 SDK is intentional for this first image: the runtime-community OpenHarmony leg is currently configured to build with the 6.0 image, and my fork CI/build recipe uses the same SDK version.
The latest fork runtime release is .NET 11.0.0-rc.2.26504.105. That is a .NET runtime version, not an OpenHarmony SDK version; it was built from the 6.0-SDK recipe and its artifacts were installed and exercised on OpenHarmony 7.0.0.109/111 (API 26) devices.
To be precise, this is a 6.0-SDK-built runtime running on a 7.0 OS, not a runtime built with the 7.0 SDK. The 7.0 SDK build would be a separate validation axis. If you prefer, I can add the 7.0 image in a separate PR and validate it with a dedicated runtime-community leg, rather than mixing both SDK versions in this change.
NOTE: AI-assisted.
There was a problem hiding this comment.
On stability: the URL is the 6.0-Release channel path, not a per-build id, so I checked the current response headers:
Last-Modified: Sat, 06 Sep 2025 10:47:13 GMT(unchanged since then)ETag: "68bc1131-944568fd"(mtime-size based)Content-Length: 2,487,576,829
The build pins the SHA256 (a315834a…) in build-ohos.sh, so if the upstream file ever changes, the build fails at verification instead of silently consuming different bits. I can't promise the upstream operator will never replace it, but a change is loud, not silent.
On naming: we already use 6.0 everywhere in the image path and tag (.../openharmony/6.0/..., azurelinux-4.0-net12.0-cross-openharmony-6.0-amd64); 6.0.0.47 only appears in the LABEL/README as the exact pinned build. If you'd rather not see the exact version in comments either, I can drop it there and keep it only in the README.
On 7.0: as answered above, this image matches the 6.0-SDK build recipe used by the runtime-community leg; a 7.0 image would be a separate validation axis, and I'm happy to add it in a follow-up PR.
One decision I'd like your input on: once dkurepa has the tarball in the storage account, should the default OHOS_SDK_URL point at the mirror (with the HuaweiCloud URL documented as a fallback), or keep HuaweiCloud as the default and let the pipeline override?
| : "${OHOS_ASSETS:=/opt/ohos-assets}" | ||
| : "${OHOS_TOOLCHAIN:=/opt/ohos-toolchain}" | ||
|
|
||
| OHOS_SDK_URL="${OHOS_SDK_URL:-https://repo.huaweicloud.com/openharmony/os/6.0-Release/ohos-sdk-windows_linux-public.tar.gz}" |
There was a problem hiding this comment.
quite certain this will get blocked by Network Isolation, we can add it to our storage account and fetch it from there tho if we're not expecting the version/binary to change often
There was a problem hiding this comment.
Yes, please — that would solve the network-isolation issue. The SDK tarball is fixed for this image:
- Source:
https://repo.huaweicloud.com/openharmony/os/6.0-Release/ohos-sdk-windows_linux-public.tar.gz - SHA256:
a315834ac133625efc912bd078f3e2b2550868d04aef1b5aa4f9679c8b3c9d8e - Size:
2,487,576,829bytes (~2.32 GiB)
Could you add it to the approved storage account and share the exact blob URL? I will switch OHOS_SDK_URL to that mirror and keep the SHA256 check.
A few questions so we match your conventions:
- Is the existing
netcorenativeassets.blob.core.windows.net/resource-packages/external/...account appropriate, and is a path likeexternal/linux/openharmony/6.0.0.47/ohos-sdk-windows_linux-public.tar.gzacceptable? - Should the blob be immutable/versioned per SDK build, or can we use a
6.0path? - Is it public read-only from the network-isolated build agents, without a SAS token?
- Is there a size, retention, scanning, or naming requirement for this asset?
NOTE: AI-assisted.
There was a problem hiding this comment.
Friendly ping on the mirror questions above — is the existing netcorenativeassets... account/path acceptable for this tarball?
If it helps, the build also accepts OHOS_SDK_SHA (not just OHOS_SDK_URL), and I can expose both as Docker build args so the pipeline can point at the mirror without touching the script. I'm happy to prepare that change as soon as we know the final blob URL.
There was a problem hiding this comment.
sorry missed this. I the netcorenativeassets is the only path we can take at this point.
Yes, we don't need a SAS token to read from it and network isolation allows it.
I'll just run this by the rest of the team before starting with the upload
Summary
Adds the OpenHarmony cross-compilation image used by dotnet/runtime#136206. The image provides the OpenHarmony Public SDK 6.0.0.47 (API 20), static OpenSSL 3.3.1 and ICU 75.1, and the
aarch64-linux-ohos-*toolchain wrappers.Contents
/opt/ohos-sdk,/opt/ohos-assets,/opt/ohos-toolchainThe SDK is downloaded from the official OpenHarmony 6.0-Release mirror and verified by SHA256:
Licensing
NOTICE.txtfiles are preserved under/opt/ohos-sdk./opt/ohos-assets/openssl/LICENSE.txt./opt/ohos-assets/icu/LICENSE./opt/ohos-sdk/NOTICEand/opt/ohos-sdk/THIRD-PARTY-NOTICES.This image does not contain the Huawei HarmonyOS SDK, Apple SDK, or Android SDK.
Image tag
The image pins SDK version
6.0.0.47; the tag uses the major/minor6.0name. The image is registered insrc/azurelinux/manifest.json.Validation
build-ohos.shpassesbash -n./opt/ohos-sdk/LICENSEand/opt/ohos-sdk/NOTICEare present.Related: dotnet/runtime#136206, dotnet-buildtools-prereqs-docker#1778.