We no longer need to install the code coverage report generator tool in the dotnet checkin pipeline because it is pre-installed on the agent. Additionally, we recently started seeing blocking errors in the dotnet checkin pipeline because it tries to install the tool through the repo's Azure feed but the tool is not cached in the feed. This change removes the install commands.
## Azure IoT Edge PR checklist:
A recent update (ca5b8af215) to `iotedge check` code fixed the way we calculate the expected current version of aziot-edged. This change makes the corresponding update to an error message in that part of the code.
## Azure IoT Edge PR checklist:
There are some additional packages that get added to packages.lock.json files when you do `dotnet build -c Release` as opposed to `dotnet build`. This change adds the release package updates to the lock files. I also removed the architecture-specific sections that got added to the lock files in our end-to-end test projects, just to cut down on noise. Those sections don't appear at all unless you do `dotnet publish -r <rid>`, and the last rid always wins.
To test, I confirmed the Build CI pipeline passes.
## Azure IoT Edge PR checklist:
To comply with security policies, this change updates the nuget (C#) and cargo (Rust) projects in this repo to resolve dependencies through a public Azure feed (which upstreams to nuget.org and crates.io), instead of directly from nuget.org and crates.io.
To support our model of adding/updating packages and to be consistent with the lock files we've enabled for our Rust projects, this change also enables lock files (named packages.lock.json) for our C# projects.
I also found a few of our Rust projects which were not using a lock file, so I added Cargo.lock files to those projects.
All packages have been saved to the feed at the versions given in the various lock files. Whether the pipelines build our code or you build it locally, the Azure feed will be used to download dependency packages. Authentication is not required.
To add/upgrade a package in the feed, you must authenticate with write credentials. For nuget, this is seemless once you install the [credential provider](https://github.com/microsoft/artifacts-credprovider#azure-artifacts-credential-provider). For cargo, the process is not so simple. Ideally, a `cargo login` before `cargo build` would allow you to seamlessly update the feed, but cargo does not currently support optional authentication with fallback to anonymous. In other words, because we allow anonymous access, cargo will not authenticate. Instead, you can use the feed's REST API directly. I updated edgelet/doc/devguide.md with a new section (edgelet/doc/devguide.md#update-a-dependency) that explains how to add/upgrade dependencies in the feed for Rust projects.
To test, I ran the CI Build pipeline (as well as the E2E-Checkin pipeline, plus all the PR check pipelines) and confirmed they all passed.
## Azure IoT Edge PR checklist:
The AzureKeyVault@1 and PublishCodeCoverageResults@1 tasks for Azure pipelines are deprecated. This change updates both tasks in YAML files across the codebase. It also updates the BuildQualityChecks task to the latest version.
I confirmed that deprecation warnings disappear from the affected pipelines.
## Azure IoT Edge PR checklist:
A recent PR converted the Ubuntu 24.04 x64 end-to-end test job to use an ephemeral 1ES-hosted agent instead of a stateful custom agent. With this conversion, we should have removed steps from the job that are only needed for stateful agents, but it was missed. This update removes the steps.
I ran the end-to-end test pipeline against this PR and confirmed that the steps are removed and the job still passes.
## Azure IoT Edge PR checklist:
1ES has added support for Ubuntu 24.04 x64, so we no longer need to use a custom agent. This change updates the end-to-end test pipeline to use a 1ES-hosted agent.
I ran the end-to-end tests against this PR and confirmed that the Ubuntu 24.04 x64 job runs on a 1ES-hosted agent and passes.
## Azure IoT Edge PR checklist:
- This PR adds an event listener to log SDK events. The event listener is guarded by the env var and otherwise should have no effect.
- Also this PR fixes the devguide to specify .net 8.
Local testing is in progress...
## Azure IoT Edge PR checklist:
Mariner builds recently started failing because the Mariner toolkit upgraded its go dependency requirement to 1.21. This change updates go in Mariner builds.
To test, I ran the CI Build pipeline and confirmed that Mariner builds pass.
## Azure IoT Edge PR checklist:
This change updates the build and tests pipelines to support Ubuntu 24.04 amd64 and arm64v8. Specifically,
- Add Ubuntu 24.04 amd64 and arm64v8 jobs to the end-to-end tests pipeline.
- Update iot-identity-service repo references in Cargo.lock so we pick up the right packages in the end-to-end tests.
- Add Ubuntu 24.04 amd64 and arm64v8 to the packages build pipeline and related scripts.
- Update markdown docs and comments as needed.
- Update end-to-end test code to support Ubuntu 24.04 packages.
To test, I ran the CI Build and end-to-end test pipelines and confirmed they pass.
## Azure IoT Edge PR checklist:
When edged sends an image pull request to dockerd, it expects dockerd to respond with the HTTP response status code and headers within 30s. The image pull itself does not need to complete within those 30s, just the initial start of the HTTP response, after which dockerd streams JSON events in the response to indicate the pull progress.
We have one customer whose device is unable to pull module images from their remote container registry. This is because dockerd needs to check whether the image exists on the ACR before it sends the HTTP response status code, and this check itself takes ~45s or so. When edged times out and abandons the request after 30s, dockerd has different behavior depending on whether the image tag is `latest` or not:
- If the image tag is `latest`, dockerd continues to pull the image in the background even after edged cancels the request. So one would think that when the image is pulled eventually, the next request to pull the image would succeed immediately. However the semantics of the `latest` tag are that dockerd must still check the ACR to see if there's a newer image available, and this also ends up taking ~45s, so the net effect is that edged continues to time out the request.
- If the image tag is not `latest`, dockerd also stops pulling the image after edged cancels the request, instead of continuing to pull it in the background. So every attempt to pull the image is canceled and the image never gets pulled to the device.
So this change increases the timeout of requests to dockerd to 60s.
***Please replace this line with your PR description and read PR checklist below***
## Azure IoT Edge PR checklist:
This change updates the build and tests pipelines to support Debian 12 amd64, arm64v8, and arm32v7. Specifically,
- In end-to-end tests, convert Debian 11 arm32v7 job to "minimal" since it will no longer be the latest supported Debian version. Since the arm32v7 jobs are very slow (they run on Raspberry Pi), we only run the full battery of tests on the latest version. On the others, we just run the TempSensor test.
- Add Debian 12 amd64, arm64v8, and arm32v7 jobs to the end-to-end tests pipeline.
- Add Debian 12 amd64, arm64v8, and arm32v7 to the packages build pipeline and related scripts.
- Update markdown docs and comments as needed.
- Update end-to-end test _code_ to support Debian 12 packages.
To test, I ran the CI Build and end-to-end test pipelines and confirmed they pass.
## Azure IoT Edge PR checklist:
TL;DR - When the cloud connection not working, the cached reported property should not be updated as it was not updated to the cloud.
Background:
There is a bug when the edgeAgent starting and trying to download docker images for the other modules, it fails to download those module docker images (cloud connection failed), so the edgeAgent throw an exception (error). Later, edgeAgent was able to download the module and continue with its operation which successfully apply the desired property to the device with version 42. Unfortunately, the interrupted edgeAgent misreported the version of the desired property as version 41 to IoTHub.
## Azure IoT Edge PR checklist:
A recent fix to the azure-iot-edge snap (#7330) changed the daemon type of the docker-proxy service to `notify` to resolve install/startup timing issues. With that fix, docker-proxy now waits until it can establish communication with Docker before calling `systemd-notify --ready` to resume and allow aziot-edged to start.
A problem was discovered once the updated snap was published to the marketplace. If a user installs the snap without --devmode, docker-proxy startup fails with: "Got notification message from PID nnnn, but reception only permitted for main PID mmmm". This happens because systemd expects the `systemd-notify --ready` command to run in the service's main process, but bash runs it in its own process. Systemd can be configured to allow other options, but snapd doesn't expose them.
This change uses the shell builtin `exec` command to run `systemd-notify` in the same process as the parent script. It also uses the --exec option on `systemd-notify` to set up socat after `systemd-notify` returns. The --exec option is new, so the snap has been upgraded to core24.
Also, the configure hook was producing config files with empty hostnames, which caused failures on startup. It's unclear why the hostnamectl command isn't working in this instance (possibly something to do with the core24 upgrade?), but it turns out to be unnecessary because `iotedge config apply` will correctly determine/populate the hostname a little later. This change removes the logic to populate the hostname field from the configure hook.
To test, I built new snaps in the CI build pipeline, ran the end-to-end tests pipeline against them, and confirmed the snap jobs pass. Since the snap jobs install with --devmode, I also published to a temporary branch in the marketplace and tested manually.
## Azure IoT Edge PR checklist:
Following a recent fix in our snap packages, our end-to-end tests started to fail. The tests need to install the azure-iot-edge snap with --devmode, at least until we get approval to auto-connect the daemon-notify interface (in progress).
This change updates the install command in the end-to-end tests to prevent failures. I ran the end-to-end test pipeline and confirmed this fixes the failures.
## Azure IoT Edge PR checklist:
This PR introduces the use of short-lived SAS tokens to get an identity using the AzureCLI task. The use of shared keys to access the blob storage account is now discouraged, prompting this change.
We don't always upload logs to the storage account, only when we want to debug something. However, log upload is currently broken after the shared key on the storage account was disabled.
This is the manually triggered test run for this PR:
- [X] I have read the [contribution guidelines](https://github.com/azure/iotedge#contributing).
With the introduction of throttling for anonymous pulls from docker.io, we've been systematically removing references to docker.io images. This change removes references to two custom images that we created years ago for cross-compiling edgelet for arm32v7 and arm64v8. By using the the `pre-build` key instead of `image`, we are able to invoke newer functionality in cross to create target environments just in time, based on the default images they maintain in the GitHub registry.
The "iotedged Checkin" check in this PR passes for Linux arm32v7 and arm64v8, confirming that the changes in this PR have the desired effect. This change was already made in the release/1.4 branch (see #7324).
Note I've also used this PR to delete a line from the edgelet dev guide that applies to CentOS 7, which is not supported in the main branch.
## Azure IoT Edge PR checklist:
This change removes a pipeline template that has been moved to our internal release repo, and is therefore no longer referenced.
## Azure IoT Edge PR checklist:
Docker has been throttling anonymous pull requests on their default docker.io registry for some time. We've avoided throttling by eliminated most of our references to base images on docker.io, but we still have one or two. Recently, one of the remaining references--the alpine image we use to build RocksDb in a container--has been getting throttled as well.
This change updates the Dockerfile we use to build RocksDb. It updates the base image to a mirrored version on mcr.microsoft.com.
To test, I ran the CI Build pipeline and confirmed that RocksDB is successfully built. I also ran the end-to-end test pipeline against the built binaries to confirm they behave as expected.
## Azure IoT Edge PR checklist:
Damon Barry
yophilav
IoT Edge Bot
Vadim Kovalyov
Arnav Singh
Gaurav Kulkarni
Stephen Mwangi