For programmatic deployments of The Things Network, we need to be able to generate tokens and to get them. Currently, when tokens are generated, they are only shown on the command output - which means getting the token requires parsing the output. It's not sustainable, since the CLI output might change over time.
This PR introduces a new option to the authorize commands, --save, which allows the user to point to a file where to save the token. This way, when programmatically deploying The Things Network, it is possible to retrieve the token safely. If this is not satisfying, we could imagine an option to hide the logs from the output.
Coverage remained the same at 74.731% when pulling ea271e3d1d39817aee26ffc9379a719a34ea1f46 on feature/save-token into 775f58d0bc86328750f614086b8b1153bfa3f51e on develop.
Coverage remained the same at 74.731% when pulling 9547bff660c7b49e33f343a04ee791c7f3fb2c11 on feature/save-token into f3610c5d31b255e18dffa3654363262478ba9a14 on develop.
Coverage increased (+0.09%) to 74.824% when pulling 1257d6d6872647a8689e1a9d8b37f64d45061ea5 on feature/save-token into f3610c5d31b255e18dffa3654363262478ba9a14 on develop.
For programmatic deployments of The Things Network, we need to be able to generate tokens and to get them. Currently, when tokens are generated, they are only shown on the command output - which means getting the token requires parsing the output. It's not sustainable, since the CLI output might change over time. This PR introduces a new option to the
authorize
commands,--save
, which allows the user to point to a file where to save the token. This way, when programmatically deploying The Things Network, it is possible to retrieve the token safely. If this is not satisfying, we could imagine an option to hide the logs from the output.