My device uses a custom capability (valleyboard16460.info).
For this reason, in my test file, I tried to load capabilities from profile (test.load_all_caps_from_profile)
The command hangs when it reaches os.execute shown below:
It only happens when executed by github workflow. Locally, it works as expected.
Currently, I bypassed that problem by committing all capabilities in the $ST_CAPABILITY_CACHE folder
This is the workflow I currently use:
In summary, 2 things:
The problem reported above
Does anyone know any working example that uses github workflow to publish the driver to a channel after running all tests successfully ?
Hi @w35l3y, great idea to test and publish from CI. Based on your workflow, I suspect the problem is that the token (via SMARTTHINGS_TOKEN) is only put into the env for your publish step and not test. I believe that adding it to the test stage may allow the CLI command being executed to complete with my theory being that the command is blocking on trying to prompt for a token via oauth without the token provided.
It’s possible that’s not the problem but that would be my guess.
I should add, that it would be good with this to ensure that the env vars including your token is not logged by anything automated by any stages including the token secret. From that perspective, limiting the token to only the publish or a smaller stage is desirable and it could make sense to define a smaller stage that would populate this info using the secret separate from the full test stage.
you are completely right!
I removed the generated .config/@smartthings/cli/credentials.json and reproduced the command that is in lua_libs-api_v3/integration_test/utils.lua and it opened the browser to login.
It didn’t cross my mind because I thought this command were public and didn’t require token. (possible new feature?)
Generally, this API and many others require a token as a baseline even if the contents are not restricted for a particular principal/user. One thing you can do would be to consider provisioning a separate token for this API access vs publish with just the required scopes which I believe for this api (API | Developer Documentation | SmartThings) would be r:customcapability. Doing so would mean that a compromise of that token wouldn’t really grant an attacker much access.
As noted separately, I’m not aware of any problems with your CI configuration that would leak the token, just providing ideas on how one could potentially provide greater isolation.
