September kicked off with some very pleasant, and warm, late summer / early autumn sunshine, at least here in Northern Europe. But Autumn has now officially landed and it brings with it a few useful little Kosli extras that the team have been busy putting together for you.
Manage your API Keys
Kosli’s API is how your runtime environments and CI/CD pipelines report your environment snapshots, artifacts, and evidence to Kosli. You can now add and remove API keys, and set an expiry for your keys.
Head to your profile settings page and you’ll see your existing API keys:
Adding a new API key is as simple as hitting the “+ Add API Key” button, and choosing the expiry time your require.
Your new API key will be available for you to copy and use in your build scripts and environment reporting!
Once you’ve updated your scripts, you are free to delete the old unused API key.
Service Accounts
As well as the changes to API Keys. We have also introduced service accounts for Shared Organizations. Service Accounts are API only users which you can use in your build scripts and environments without being tied to a specific person. As an Organization administrator, you can manage your service accounts from your Organization settings page.
When you create your Service Account, you can specify its name and the expiry for the default API key.
Service accounts have the same API management capabilities as mentioned below, which are all available from the Service Accounts section of your Organization settings page.
Artifact Reporting
We’ve made a few updates to help you with artifact reporting using the Kosli CLI.
Exclude files and sub-directories when reporting directory artifacts
Kosli supports reporting a directory on the file system as an artifact. Using the –artifact-type dir flag and passing the directory path, the Kosli CLI will calculate the fingerprint for you. Sometimes, there are files and sub-directories in that particular directory that you don’t want to include in the fingerprint as they will not be present, or are expected to change, in the runtime environment. Using the new –exclude flag you can now ignore them.
kosli report artifact pkg \
--artifact-type dir \
--exclude .secret,pkg-logs
See the CLI Reference for kosli report artifact
for more information.
Provide a custom display name for an artifact
The kosli report artifact command will try to name your artifact based on the file path, directory path, or docker image name that you are reporting. Sometimes, it can be nice to have more control over the name that we use to display the artifact in Kosli. Now, you can provide the name using the –name flag:
kosli report artifact C:\build\loancalculator-website\pkg.zip \
--artifact-type file \
--name loancalculator-website:v1.4.5
See the CLI Reference for kosli report artifact
for more information.
Always resolve the underlying git revision, before saving artifact data
When you report an artifact using the Kosli CLI you must include the Git commit sha from which the artifact was build, using the --git-commit
flag. Typically, this is collected automatically by the Kosli CLI in your CI/CD system. Sometimes, this can be reported as the sha of an annotated tag, rather than the actual commit, which would lead to Kosli not correctly displaying the commit information or providing simple traceability back to the commit.
To solve this, the Kosli CLI will now resolve the value passed into --git-commit
flag back to the sha of the actual commit.