Gitlab
Learn how to setup Gitlab CI pipelines so publishing your data science work becomes automatic!!
Last updated
Was this helpful?
Learn how to setup Gitlab CI pipelines so publishing your data science work becomes automatic!!
Last updated
Was this helpful?
Have a Kyso account - either on kyso.io or on your company's private Kyso installation.
Create a Kyso access token - follow these . Save this for later!
Ensure your directory (or ) contains a valid kyso.yaml file. Check the following for more info.
About the kyso-push step variables:
Theusernameand token fields take their value from secret variables, to make the system work the user has to create the kyso auth token and define the KYSO_USERNAME and KYSO_TOKEN as explained on the .
Create your Access Token according to this document:
Theurl has to point to your Kyso deployment. So if your company, Acme Inc. has its own Kyso instance available on https://acme.kyso.io, that is the value that has to be assigned to it.
Create a .gitlab-ci.yml file in your Gitlab repository.
Copy the following YAML contents into .gitlab-ci.yml:
We're using node version 18 here, note that this might need to change if looking at this doc in the future. This works as of September 27th 2022.
This means that on each new push to a tag on the repository, a CI pipeline will be generated to run the commands in our action file above.
Remember to also ensure that your metadata specs in the sub-directory YAML files, are correct:
organization: [Your Organisation Name]
team/channel: [Destination channel for each report, and this might be different for each sub-directory]
When we commit changes to the Gitlab repository, a Docker image is created to run our job. We can check out the pipeline logs at https://gitlab.com/user/repository/-/jobs/job-id and should see something like this:
So, for example, if you work with a team of scientists, data scientists, etc.., all pushing and pulling to and from the same repository, you're going to want to control how, when and what changes get published to Kyso.
Because a merged pull request always results in a push, we can just use the push event to accomplish our goal. So the above workflow will run when a PR is merged or when a commit is made directly to the master branch.
To make this workflow even more secure, it has been recommended that you add branch protection rules to your main branch!
Similar to our documentation on Github Actions,