CI: Add check-dependencies workflow #41
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* Restructure commands organization * Restructure mqtt package * Split ping in cli and command * Rename ping params
* Wrap arduino-cli commands into a client * Implement grpc client for arduino-cli commands * Rename arduino interface Client to Commander * Implement binary upload
Introduce iot package to wrap the arduino iot-client-go. This allows to perform cloud operations in a simple and transparent way, like adding a device, exploiting the iot-api rest interface. * Wrap iot client go * iot client - implement add certificate * Refactor iot wrapper as internal package - Move iot in internal package - Add significative comments - Rename auth.go in token.go
Introduce a wrapper of serial (https://github.com/bugst/go-serial) for sending commands to arduino devices connected to the PC through the serial port. Commands and responses follow the protocol defined by the provisioning firmware (https://github.com/ubidefeo/Arduino-CLI-provisioning/tree/main/ArduinoIoTCloud-CryptoConfig). * Wrap serial * Refactor serial wrapper as internal package - Move serial into internal package - Add comments - Do not export 'retrieve' function - Transform magic numbers into readable constants
iot-cloud-cli should be configured before being used. In particular a client ID and the corresponding secret ID should be set.
The config command is used to configure these two important parameters.
It accepts either :
two flags: -c and -s for configuring respectively the client id and the secret id
a configuration file in yaml format containing the two parameters
Also, the internal packages of iot-cloud-cli can retrieve this configuration by using the Retrieve function of the internal/config package.
* Add config command
* Restructure config into internal package
- Use config as an internal package
- Add significative comments
- Change error message format
* Split config in cli and command
This PR introduces a command to provision arduino devices. It must be executed on a computer with an arduino device connected via USB. This command does everything needed to provision a device, including creating the device in Cloud, but also running the initial provisioning sketch that generates proper certificates to store in secure element. When using this command, you can optionally explicit the port which the device is connected to and its fqbn. If they are not given, then the first device found is provisioned. Usage: $ iot-cloud-cli device create --name <deviceName> --port <port> --fqbn <deviceFqbn> * Add local provisioning binaries * Add device command * Implement provisioning Fix log format Fix - add delay Fix - use same flag as arduinocli * Hack - don't check errstream from cli Problem: Uploading the provisioning bin to a portenta Description: even if the upload gets completed, the errstream from the rpc client of arduino-cli is not empty. It contains this: %!w(<nil>) Temporary solution (hacky): don't check the errstream * Split device create into cli and command Fix * Update readme
The host is not required, it defaults to production's mqtt brooker.
With the addition of the `device` command it could be confusing what `username` and `password` refer to (are they a virtual device's ID and secret or are they an IoT API client ID and secret?).
-clarified two steps in the how-to
* Add our standard PR template * Update main branch name
arduino-cli packages have been imported in order to directly call the arduino-cli commands packages. This allows to remove arduino-cli daemon as a requisite. Moreover, this completely remove the needs to have arduino-cli installed. Compile is not required at the moment * Remove compile from commander interface * Implement cli commander * Update readme
mqtt diagnostic and debugging commands are moved into another specific tool. This PR removes the ping command and all its dependencies (mqtt, codec etc..)
This PR introduces the device list command, useful to retrieve devices of arduino iot cloud.
To list devices, no flags or arguments are needed, the command is simply:
$ iot-cloud-cli device list
maybe worth doing in the future:
list command could accept a list of IDs that should be retrieved from the cloud
edit: a new show command might be better
commits log:
* Add device list command
* Add comments
* Update readme
This PR introduces the command to delete a device from arduino iot cloud Thus, now devices can be created, deleted and listed To delete a device, a device id should be specified $ iot-cloud-cli device delete -i <DEVICE_ID> * Add device delete command * Update readme
things can be created in two ways:
- starting from a template. templates can be extracted from existing things
- cloning another thing, already available on arduino iot cloud
The parameters to create a new thing are:
- thing name - mandatory
- device (id) to bind the thing to - optional
- thing template - mandatory if no thing to clone is passed
- thing to clone (id) - mandatory if no template
commits history:
* Add thing create command
* Check clone params before copying
* Thing create uses updated iot-client-go
Given that iot-client-go has been updated and now supports the creation of things with a slice of properties, it's been here employed to create a thing.
Issue: response's error details, coming from arduino iot cloud, are masked by iot-client-go
* Add optional
* fix thing create - improve flags
* Update readme
Things can be printed thanks to a list command.
Also, properties belonging to the things can be printed, by passing the --properties flag to the list command.
$ iot-cloud-cli thing list --properties
The following parameters can be used to filter out the resulting list:
- ids : is a list of thing IDs. Only the things belonging to this list will be printed out.
- device-id : only the thing associated to this device will be printed.
commits history:
* Add thing list command
* fix thing list typo
* fix thing list - improve flags
* Update readme
Things can now be deleted with the following command: $ iot-cloud-cli thing delete --device-id <deviceID> * Add thing delete command * Update readme
Extract a template from an existing thing using this command: $ iot-cloud-cli thing extract --id <thingID> --outfile <templateFile.json> outfile parameter is optional, it specifies the json destination file for the template * Add thing extract command * Update readme
Bind command is used to bind a thing to a device: $ iot-cloud-cli thing bind --id <thingID> --device-id <deviceID> * Add thing bind command * fix thing bind - improve flags * Update readme
adapt cloud-cli thing templates to the already established concept of template: - extracted templates are more "compliant" with the already known templates - standard cloud thing templates can now be used to create new things * Adapt template extraction remove properties_count, max_value, min_value, persist and tag fields add template name field change helper to remark that a template is being extracted instead of a thing. * Adapt thing creation to rfc thing create command has been split in two commands: - thing create -> create a thing from a template. name parameter is optional and, if it's present, it overrides the name provided by the template - thing clone -> create a thing from an existing thing. name parameter of the new thing is mandatory thing templates have been aligned with general iot cloud templates concept now templates like this: https://github.com/bcmi-labs/cloud-templates/blob/main/templates/home-security-alarm/resources/thing.yml can be directly used to create new things. * Replace Properties with Variables * Update readme
Additional details are extracted from errors returned by iot-client-go. This change allows to return more appropriate error details.
All implemented commands now accept optional parameters as pointers. This change makes the command package more clear and easier to use: if the type of a parameter is a pointer, then it becomes clear that such parameter is optional. So, for example, instead of an empty string now it's possible to pass nil for optional parameters.
Thing templates are now supported in both json and yaml formats. This means that, during the thing creation, the thing template can be passed either as json or yaml file. On the other hand, during the template extraction, the user can specify his preferred format with an appropriate flag. The default value for the format is yaml. $ ./iot-cloud-cli thing extract --format json * Thing template - Support both yaml and json formats * Update docs * Extract template supports multiple formats * thing extract - set yaml as default format * Update readme
Allows users to choose an output format between text and json. Writes to stdout (through fmt.Print..) have been replaced into writes to a logger. If the verbose flag -v is passed to the command line, then the logger will be enabled. Otherwise, all the logs messages will be discarded. These changes allow users to save results in files. For example, with the following command, a device is provisioned and its properties are written into a json file: ./iot-cloud-cli device create --format json --name <deviceName> > deviceName.json * Replace fmt print into log info * Distinguish board from device * Improve device format output * Fix log infof * Improve logs of arduino-cli This commit has two effects: - arduino-cli init command logs are masked out. - arduino-cli upload logs are logged only if logrus was already enabled. * Fix log msg * Update go mod * Improve thing output format * Refactor thing output format * Fix device iot client * Improve errors: use stderr and error codes * cli package: don't return error * Remove unreachable code * Improve log initialization * Remove duplication of info messages * Add arduino-cli source to upload logs * Return consistent output
The ota flow is the following: the device to be updated should be already provisioned and online. The user should have a sketch locally. This sketch must be compiled through arduino-cli or arduino-ide1/2. Then, this command should be used in order to start the upload: $./iot-cloud-cli ota upload --device-id <deviceID> --file <sketchName.ino.bin> * Import ota generator * Implement ota generation * Add ota upload command * Adapt to format-output changes * Fix typos * Improve ota upload help * Add deferred option * Improve deferred ota * Update readme
config command is changed into config init. Secrets cannot be passed anymore as input parameters. Instead, this new command create a skeleton to be manually filled: $ iot-cloud-cli config init --overwrite --dest-dir <destinationFolder> --config-format <json|yaml> It allows to specify a directory in which the configuration file will be initialized. Also, the optional overwrite flag indicates that if a config file already exists in that folder, it will be overwritten. Moreover, the configuration file can be written in both json and yaml format. * Refactor config command * Support multiple config formats * Rename config format flag * Update readme * Update readme
On every push and pull request that affects relevant files, run the project's Go code tests. * CI: Add test workflow * Disable code-coverage
Add a github workflow that uses a Taskfile to cross-compile the project for the main operating systems. The gon configuration, used to notarize the binary for mac-os, has been fixed. A new release will be generated on every push of a tag named with a version format. * CI: Add release workflow * Disable upload to aws * Enable macos notarization * Edit release archive (- license, + binaries) * Fix release version * Add todos
Hi @polldo. The license file detection system used by the Licensed tool is very strict, which is actually a good thing because even a small difference in wording or even punctuation might completely change the legal meaning of a license, and the tools are not smart enough to reliably interpret whether such a change is significant. So it will be inevitable that human review will be needed for some dependencies. This can take some time to do when the system is first set up because of the large number of existing dependencies that must be analyzed, but I think it won't be so much ongoing work after that initial set up because it won't be too often that new dependencies are introduced, and the tool does automatically detect the licenses of many dependencies. The human review process for dependency licenses that could not be detected:
A dependency might use a license type that can not be allowed globally via the In this case, the dependency's identifier must be added to the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
This branch is needed to check if dependencies of the project are compatible with its license.
Right now, it cannot be merged because many dependencies have a custom license that is not recognized by the workflow.
Change description
Additional Notes
Reviewer checklist
main.CONTRIBUTING.md) and are well formatted.