pin last `vega-lite` version to support node16

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[shcheklein]

Thanks @dacbd !

• Is it a big undertaking to upgrade those images?
• Could you please remind - what is the difference on using them vs setup-cml. What is the main use case? Do we want to keep maintaining them?

[dacbd]

This patch is a relatively simple undertaking.

As far as maintaining both, I would consider the docker images to be in maintenance mode. The thing that bothers me the most is that the cml release workflow is very fragile in its current state, so creating as few releases as possible is my preference. The last few releases have always had some issues.

setup-cml is much easier to maintain, and is what I always recommend. The couple of times users have wanted a container image I've recommended they take a look at our Dockerfile in the repo as an example to create their own image with everything they need for their use-case.

IMO if you are using docker images for your project pipelines you shouldn't use any setup-* style actions. Those tools should be built into your image with pinned versions so you have the exact stable environment you want/need.

[shcheklein]

Is setup-cml available only for GH though? Pretty much in general people have to use cml images, no? btw, do we have the dvc3 version of it (probably need to update the website and docs)

[dacbd]

Is setup-cml available only for GH though? Pretty much in general people have to use cml images, no? btw, do we have the dvc3 version of it (probably need to update the website and docs)

Yes BB pipelines and gitlab-ci don't have anything similar (to setup-cml) and are essentially based on containers.

People don't have to use the CML images still they can install cml into with own image, or use @0x2b3bfa0's curl https://cml.sh/ | sh. Personally, I've always viewed the cml docker images as "getting started" tools that have a nice bundle of tools to help get you started.

Yes we builddvc3 images also, if the docs do reflect that we should probably update them.

[shcheklein]

okay, fine then ... let's pin the images and probably bump the website to use dvc3. No need to spend too much time on it for now. I'm a bit worried that Node 16 is out of support now. So, probably we should put a note somewhere on the website as well that we don't recommend using those images - they are just an example.

[janrito]

As far as maintaining both, I would consider the docker images to be in maintenance mode. The thing that bothers me the most is that the cml release workflow is very fragile in its current state, so creating as few releases as possible is my preference. The last few releases have always had some issues.

It would be nice if this was mentioned in the documentation. Currently, it seems like your recommendation is to use these images to run pipelines in self-hosted runners

setup-cml is much easier to maintain, and is what I always recommend. The couple of times users have wanted a container image I've recommended they take a look at our Dockerfile in the repo as an example to create their own image with everything they need for their use-case.

I don't have much experience outside github - however, even in github you need to use the setup-cml action to start the self-hosted runner, so the obvious thing would be to use it to setup the runner as well. Currently we set up cml in two different ways for each pipeline.

This is a bit confusing. But even so, if this is the recommended process, it maybe should be in the documentation?

IMO if you are using docker images for your project pipelines you shouldn't use any setup-* style actions. Those tools should be built into your image with pinned versions so you have the exact stable environment you want/need.

I agree that advanced use-cases are probably better off creating their own image. The issue is that for a good number of cases, these images are probably going to be quite simple: cml (and the node version that works for v2png), git, and the starter tools requirements to setup a specific version of python, via setup-python. This is what the provided images did well, and would get most people what they need.

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment

[github-actions[bot]]

Test Comment