118/feature/docker ci

[AaronYoung5]

No description provided.

[AaronYoung5]

@StefanCaldararu kinda hype, no longer need to build. I've just built some cross-platform images on my machine and pushed them. I want these images to be updated whenever a commit happens on master, but it's hard to test the github action since it needs to be in master. I think it works (i tested the gh action locally at least).

https://hub.docker.com/repository/docker/uwsbel/art/general

[StefanCaldararu]

@StefanCaldararu kinda hype, no longer need to build. I've just built some cross-platform images on my machine and pushed them. I want these images to be updated whenever a commit happens on master, but it's hard to test the github action since it needs to be in master. I think it works (i tested the gh action locally at least).

https://hub.docker.com/repository/docker/uwsbel/art/general

sweet I'll take a look in the AM, at the airport rn. Trade PR reviews?
(p.s. documentation doesn't count)

[StefanCaldararu]

Lots of questions:

• Still have to build art-oak even though it is a service in main?
• Can't build other branches, so I don't really see this getting a ton of use. Everyone is using other branches, and all development happens on other branches (not master), so how does this help much? ig if your branch is similar enough to master you can pull the built container and then switch branches, right? But everyones branches are still pretty far behind so won't be able to use this
• you mentioned pushing a new image every time a commit happens to main. This seems like there will be some pretty extreme data storage / etc. What happens when I just push a documentation change, for example? Wouldn't it make sense to just have more of an "abbreviated" history of images that is kept up to date?

[StefanCaldararu]

why is this not default to true?

[AaronYoung5]

Cause we can't push optix binaries/source, against the terms

[AaronYoung5]

Still have to build art-oak even though it is a service in main?

By default, only chrono, dev, and vnc are pushed. But you can push a local image with atk dev -c push -s <service>. Github doesn't have agx/jetsons connected to github actions, so not possible build agx images there.

Can't build other branches, so I don't really see this getting a ton of use. Everyone is using other branches, and all development happens on other branches (not master), so how does this help much? ig if your branch is similar enough to master you can pull the built container and then switch branches, right? But everyones branches are still pretty far behind so won't be able to use this

I mean this is also true for any change we make to main rn, right?

you mentioned pushing a new image every time a commit happens to main. This seems like there will be some pretty extreme data storage / etc. What happens when I just push a documentation change, for example? Wouldn't it make sense to just have more of an "abbreviated" history of images that is kept up to date?

I think this makes sense, like the action isn't on by default, you have to explicitly run the action. As a note, docker images are layers, so like each RUN command is an additional layer on top of the FROM image you built with. So if a change happens that doesn't effect the image, i.e. docs, no additional information is actually stored on dockerhub since no layers changed. Does this make sense? Does this change your opinion here?