Are there plans to allow definition of lockboxes via platform API?
I cannot find any information on this and the current process (having to define it via the web interface) is not desirable in the long term when we wish to automate this process via CI system wherein the build
knows which components (compose, OS) should go into the lockbox as part of a build chain dependency.
There is API available to interact with our platform however it is still somewhat not public. When I say not “public” I mean in the sense that it is mostly undocumented as the team is still working on polishing the API for public use. That said the actual API endpoints are publicly accessible if you know what they are.
You’ll need to know the backend names and information of the packages that are to be included in the Lockbox. For authorization you’ll need a token that you can get from defining an API client in the Web UI.
Here’s an example of getting such a token:
CLIENT_ID=<API CLIENT>
CLIENT_SECRET=<CLIENT SECRET>
TOKEN_URL="https://kc.torizon.io/auth/realms/ota-users/protocol/openid-connect/token"
# Token produced here is usable for all API endpoints.
# Token expires after 7 days.
TOKEN=$(curl $TOKEN_URL \
-d client_id=$CLIENT_ID \
-d client_secret=$CLIENT_SECRET \
-d grant_type=client_credentials | jq -r .access_token)
Once you have that you can use it to make a call to an API like so:
That said keep in mind that our API is still not 100% polished and ready for public use so some issues/difficulties are somewhat expected. Though we are planning to make it ready for public use.
Fantastic, thanks. I’ll have a look at this now!
Rough around the edges is fine for now since I’m in the process of setting up the infrastructure and we are not yet at a state where it will be needed in a production context.
Is there a field that can be used to set the expiry of such a created lockbox? I do not see it defined and attempting to simply add “expires” as a json key wasn’t successful - while not rejected by the server, it still defaults to 1 year.