@Phil has joined the channel
@my-janala has joined the channel
@Ziad Hilal has joined the channel
@jylee has joined the channel
@Michael Pereira has joined the channel
@michal.matyjek +1 for hadolint as I believe it’s based on the excellent shellcheck, which makes sense since Dockerfile are mostly just a collection of shell commands
so it benefits from the existing shellcheck rules
@dat.le has joined the channel
@Max Moon we are about to merge https://github.com/cloudposse/build-harness/pull/85
What Use helm package to change version and app Version of chart Use convention that default image tag is based on app Version Create promote targets that allow to promote chat to required versio…
This adds the ability to promote images and charts between repositories
We suggest adopting this as your production strategy
There are some minor breaking changes which @Igor Rodionov will document
(related to renamed ENVs)
@antonbabenko has joined the channel
On this topic - maybe it’s my misunderstanding of helm? but kinda bothers me that chart version would rev with appVersion (they don’t have to match of course). Or is it OK to keep these decoupled in say, dev, and only revision chart version on promoting to staging/production? Don’t use appVersion in charts at all? What’s the right strategy?
(this is loosely related to the PR above)
but kinda bothers me that chart version would rev with appVersion (they don’t have to match of course).
@michal.matyjek this strategy is designed for repos where we cotenant the chart with the app itself. if the chart is not hosted in app repo, then it’s a much more difficult problem to solve.
I don’t see the benefit of treating an app as a “monorepo” just because it also contains a chart. that is, treating the “chart” as one app, and the service itself as another “app”. If the chart and app are in the same repo, then they are the same version IMO.
that said, we’re investing now in a monochart.
what add monochart (moved from helm-chart-scaffolding) references #5 #6 #8 #9
this is one chart to rule them all.
it’s still a WIP with lots of comments. @alebabai is working on it.
The idea is to get out of the business of writing charts and just defining
…to stop allowing every service to be a snowflake and instead take the Heroku approach where you write a service that conforms to certain principals and then the monochart just works.
Plus, the monochart is composable, so you can create a service with multiple components just by creating an umbrella chart
@alebabai has joined the channel
@michal.matyjek any recommendations for alternatives to “bats”?
nothing comes to mind, but looks like you are picking
yea - just needed to move forward to something. still in the prototyping phase. it can be replaced with something else.
seems like it’s no longer maintained
though looks like
bats-core is maintained
Travis is using bats
terraform-config - Terraform bits and bytes
@Sebastian Nemeth has joined the channel
Submitted some PRs against geodesic to make it easier
For now, I’m going to be using Codefresh because it’s easier to iterate than using codebuild/codepipeline
as it relates to infrastructure, I see it boils down to a few different use-cases
- testing terraform modules (including
- testing helm/helmfiles
- testing account-level infrastructure
for our purposes, I’ve ruled out atlantis and test kitchen, at least at this phase. I want something that lets us test more holistically, since what we need to test is the integration of lots of systems across languages, tools, and binaries.
for this reason, I am leaning towards using bats (bats-core) - or a tool like it
bats-core feels very lightweight, which I like.
bash as a “top most level” language for integration also feels right. it doesn’t preclude us using other purpose-built testing frameworks for individual languages or apps.