canonical / specs.canonical.com

2 stars 9 forks source link

Added docker build env defaults #150

Closed samhotep closed 1 year ago

samhotep commented 1 year ago

Done

QA

webteam-app commented 1 year ago

Demo starting at https://specs-canonical-com-150.demos.haus

andesol commented 1 year ago

@samhotep Didn't work. This site is a bit different because we execute a command at build time, so it may not work with the usual demo workflow? See jenkins job

samhotep commented 1 year ago

@samhotep Didn't work. This site is a bit different because we execute a command at build time, so it may not work with the usual demo workflow? See jenkins job

I've noticed.. I've made some changes - let's see if it takes

andesol commented 1 year ago

Thanks for looking into this @samhotep!

The reason why the json file is generated at built time is for specs.c.c to be deployed with the specs ready to be displayed, without having to read the spreadsheet at run time. It was supposed to be a quick fix, so I haven't really explored all the possibilities.

With this setup, what would happen if the json file fails to be generated? Will k8s keep the old pods, or rather the website will fail to go live? (Maybe it's so unlikely that is not even worth thinking about it).

samhotep commented 1 year ago

Thanks for looking into this @samhotep!

The reason why the json file is generated at built time is for specs.c.c to be deployed with the specs ready to be displayed, without having to read the spreadsheet at run time. It was supposed to be a quick fix, so I haven't really explored all the possibilities.

With this setup, what would happen if the json file fails to be generated? Will k8s keep the old pods, or rather the website will fail to go live? (Maybe it's so unlikely that is not even worth thinking about it).

Yeah, in k8s if the pod startup doesn't succeed it won't delete the old pods. In Jenkins the deployment job will stall and eventually fail so we'd have to fix the issue before the site goes live.