My Workflow
This workflow is designed to register a new Azure IoT Edge Device on an existing Azure IoT Hub. I made my own custom docker action to handle setting up the azure cli, and read from a file in your repository which is a list of device names you'd like registered on your hub. Once the devices are registered on the hub, you can get their connection strings, and use the hub to deploy code to them as well. See the additional info section for more on that later in this article.
This isn't being used by anything yet, it is just a proof of concept for the actionsHackathon submission.
on: [workflow_dispatch]
jobs:
register_iot_job:
runs-on: ubuntu-latest
name: A job to register an IoT Edge Device on Azure IoT Hub
steps:
- name: Checkout
uses: actions/checkout@v2
- name: Register step
id: register
uses: rdlucas2/actionsHackathonSubmissions@v0.0.9
with:
azure-sp-client-id: '${{ secrets.AZ_SP_CLIENTID }}'
azure-sp-password: '${{ secrets.AZ_SP_PASSWORD }}'
azure-tenant-id: '${{ secrets.AZ_TENANT }}'
azure-iot-hub-name: '${{ secrets.AZ_IOT_HUB_NAME }}'
device-list-file-path: '/github/workspace/devices/list.txt'
I added secrets for my azure account information, although it wasn't necessary for some of them to be secret. The last item on the list, "device-list-file-path", is just a text file with each line containing the name of a device you'd like registered on the hub - which is why the checkout step is necessary. It is important to note that when you use a docker action, it will automatically pull in /github/workspace as a volume in the container.
On a successful run the devices should appear in your IoT Hub. Note that if a device was already registered, it will show an error message, but it should continue to register other devices and won't overwrite any existing.
Submission Category:
Interesting IoT
Yaml File or Link to Code
rdlucas2
/
actionsHackathonSubmissions
playing around with actions
Register Azure IoT Edge Device
This action Registers a new IoT Edge Device on a given Azure IoT Hub.
Inputs
azure-sp-client-id
Required Azure Service Principal Client ID.
azure-sp-password
Required Azure Service Principal Password.
azure-tenant-id
Required Azure Tenant ID.
azure-iot-hub-name
Required Azure IoT Hub Name.
device-list-file-path
Required Device List File Path.
Outputs
None
Example usage
uses: rdlucas2/actionsHackathonSubmissions@v0.0.1
with: azure-sp-client-id: '${{ secrets.AZ_SP_CLIENTID }}' azure-sp-password: '${{ secrets.AZ_SP_PASSWORD }}' azure-tenant-id: '${{ secrets.AZ_TENANT }}' azure-iot-hub-name: 'MyExistingHubName' device-list-file-path: '/devices/list.txt'
**Yaml file**
For this one, I created my own custom action, but then used the checkout action and my custom action in concert to read device names from a file in the repo, and register them on the Azure IoT Hub. I did not register this action on the marketplace yet, but have created some pre-release candidates of it. I'd move it into it's own repository instead of utilizing my actions hackathon repo.
Additional Resources / Info
Used the tutorial here for some of the setup: IoT Edge Linux Quickstart.
If you examine the code I wrote, you'll see I followed the IoT Edge Device tutorial linked above, and used ARM to deploy an azure vm with the IoT runtime on it, using the newly registered device's connection string to it. I then went into the portal and deployed the "simulated temperature sensor" marketplace code to this device through the portal page on the hub. I think this workflow could be built out to manage devices on an azure IoT hub. In addition to adding new devices, you could build out actions like deleting devices, deploying code to devices, and perhaps even collecting telemetry from devices. This was mostly a learning opportunity for myself. I had made a few other entries utilizing actions created by other individuals, and this one I wanted to explore custom docker actions.
I'm determining the proper workflow for this, as it might make sense to combine this in some way with a deployment action, where when you connect a new device, it can reach out to a repository to register itself on the hub, then update the hub connection string, deploy some code to the device with that updated connection string, then go about collecting telemetry from the device. I certainly learned a lot about how actions behave from this experience. Here are some links to my other submissions:
Top comments (0)