Release 2.6.0

[jenia81]

• Add support for an external signing tool
  • The feature enables to use of an external signing tool for signing the manifest.
  • Add a new CLI option --signing-tool to the manifest-dev-tool init command.
  • The --key CLI option of the manifest-dev-tool init command can receive an identifier private key or a private key file name that will be used to sign the manifest with the external signing tool provided.
  • Add a new configuration option signing-tool that is used by the manifest-tool create command.
  • The --key CLI option of the manifest-tool create or manifest-tool create-v1 command can receive an identifier private key or a private key file name that will be used to sign the manifest with the external signing tool provided.
  • Add unit tests for the new feature.
• Update requests to 2.31.0.
• Update cryptography to 41.0.4.
• Add support for Python 3.11 (super inits, imports with try, tox additions etc.).
• Update dev-requirements:
  • Update pytest to the latest 7.4.2.
  • Update pylint to 2.17.7 (3.0.2 does not support older versions of Python).
• Remove the --force CLI option that was deprecated already.

[jenia81]

@JanneKiiskila Please check the code scanning errors The logs are only for the certificate path, not its content And I wouldn't drop them since it helps with debugging

[JanneKiiskila]

@jenia81 - cleared false positives with comments. Resolved comments.

[jenia81]

@JanneKiiskila dropped the cron job from the GitHub action It's a bit tricky to add the condition to the workflow I can add it before the steps like this: if: github.repository == 'PelionIoT/manifest-tool' && github.event.schedule != '0 0 */3 * *' But then the job will start its execution so the machine will be allocated, just the execution time will be shorter. The only way to make sure that it won't run at all is to create a difference between the workflow files in internal and public repos

[JanneKiiskila]

The only way to make sure that it won't run at all is to create a difference between the workflow files in internal and public repos

I think we will be fine with that.