@Zachary Loeber has joined the channel
cloudposse/atlantis:latest supports 0.12.16 ? AFAIK it downloads any version, right ?
it can download TF versions specified in config
in our Docker container, we install atlantis and TF version what we need, and atlantis just uses it
is that by env variable ?
DEFAULT_TERRAFORM_VERSIONand then it goes on the loop to download the versions
my Dockerfile :
FROM segment/chamber:2 AS chamber FROM cloudposse/atlantis:latest \# install terraform binaries ENV DEFAULT_TERRAFORM_VERSION=0.12.16 COPY --from=chamber /chamber /bin/chamber COPY atlantis-repo-config.yaml / ENTRYPOINT ["/bin/chamber", "exec", "ecs-atlantis-test", "--", "docker-entrypoint.sh", "server"]
I just copy the command from the fork that downloads terraform
I don’t think we shop an atlantis container
If we do, it is out of date or not maintained
We distribute Atlantis as an alpine package
That we install like the other tools
so you are saying that the image in docker hub is unmaintained and I should not use it ?
so to use the fork you guys have I will have to build from the repo/fork you guys have
is that a correct assumption ?
Yes, and let me explain
our fundamental position on this is that running “alantis” from some kind of shared docker image is more or less useless
it doesn’t solve how custom providers get installed
it doesn’t solve how any other tools or dependencies will get installed
if someone depends on helm, helmfile, terragrunt etc…. it won’t do much good
that’s why we distribute the package instead so that it can be installed in a docker image you control
In our model, we use
cloudposse/geodesic as our base image (which is up to date)
and then add the exrta tool we depend on.
I completely agree, make sense
and you guys do no host those alpine packages I guess
if I want to use your fork
oh we do!
Add something like this to your dockerfile
cloudposse-atlantis is the naem of our package from our fork
Also, check out the other packages we have
dozens and dozens
thanks to @Zachary Loeber
this is awesome, well I’m glad I got it working with the old image at least to do my demo
now I will update
it was VERY hard to get my head around this
and….I might have found a bug
a master class in ECS/Atlatnis/codebuild/modules/etc
I would like it to be simpler
I think there is a problem with the example….
https://github.com/cloudposse/terraform-aws-ecs-atlantis/blob/master/examples/complete/main.tf#L42 this guy will create a default TG
Terraform module for deploying Atlantis as an ECS Task - cloudposse/terraform-aws-ecs-atlantis
well what happens is that the ingress module creates a TG and the alb module too
but the alb module listener rule uses the alb-default TG
instead of the one created by https://github.com/cloudposse/terraform-aws-alb-ingress/blob/master/main.tf#L20
Terraform module to provision an HTTP style ingress rule based on hostname and path for an ALB using target groups - cloudposse/terraform-aws-alb-ingress
I think so….
I got pretty confused when following the dependencies
I think I did something wrong
did you figure it out?
I have no tried yet again, I’m going to do some cleanup and see but I think this could be the ingress module. I created a PR long ago that was merges to allow to pass a target group arn in case the target groups were created by other means, so i think this could be a case were the alb module is creating the TG and the ingress module too.
so maybe is a matter of passing the TG arn
but I need to test my theory
Any notes on how you guys at Cloud Posse or others that manage many modules as separate repos do your release process? It would be greatly appreciated.
I see the makefile works as the runner for the unit tests which is awesome and I’m assuming happens upon merging to master for module X. But what determines module X is ready to release into an new version? A global find and replace of the old version tag to the new, run all unit & integration tests & if all pass push release?
@IckesJ we talk about it here: https://github.com/cloudposse/docs/issues/335
what it's not clear how we currently do versioning why our strategy is unique because we tag every single merge to master our versioning strategy allows us to systematically and consistently in…
basically, every time you merge to master, you bump the version.
bugs = patch releases
every other release is a minor release.
major releases are milestone driven.
keep in mind that pre-1.0 has a special meaning in semver
@Julian Gindi might have some more thoughts on this.
@Julian Gindi has joined the channel
Welcome @Julian Gindi !
(he just did a big presentation at a local meetup on semver and when/how to bump versions)
IMO, the main purpose of semver is not to communicate the stability of the functionality. that’s almost impossible to guarantee. even a bug fix can be a breaking change for someone else who had a workaround for that bug.
I assume that every change could be breaking for someone.
therefore, IMO the purpose behind semver is to pin software so it only changes when you expect it to.
thus, I hate it when projects don’t cut a release for every merge to master.
and that’s why I prefer every merge to master to have release so I can gauge our distance from the latest release.
git sha’s suck for humans.
All of this I agree with, I do think you can add safety and a bit of structure to internal API’s and set rules on which services can talk to what, but it’s most powerful when used as a final “resolution” for software and being able to see how things change over time.
I have a tool to help with this process, but it’s almost identical to what Erik suggested
do you have a recording of your talk?
This is awesome info guys! Thanks & would love to see/hear the recording
Here is a repo that might “automate” the boring mechanical bits of incrementing semver https://github.com/JulianGindi/auto-semver
A small python tool that aims to let you focus on writing software, while it versions it for you. - JulianGindi/auto-semver
That looks like a great package, and seems more mature. I think the only issue I have with it is that it seems to require me to pass in the current, while my script automatically determines that based on git tags. Not sure if this script is able to do that, not clear on first glance.
My approach was also a bit more simplicity, but I’m going to dig into this tool a bit, I rather use and support a tool that has a larger community if it accomplishes my personal needs
thus, I hate it when projects don't cut a release for every merge to master. 100% @Erik Osterman
• Recording of the whole presentation//vimeo.com/388711413> (including @Julian Gindi’s talk on SemVer)
• Julian’s deck and notes on SemVer//gindi.io/semver.html>
• Industry Updates slides//slides.com/coreygale/west-la-devops-5-versioning#/4>
A presentation created with Slides.
Thanks @Corey Gale
No problem thanks again for all your support!
@Julian Gindi did you consider showing a github actions code snippet that can be used to automate the semver stuff with your tool?
So we have some bits and pieces, but I should 100% add something like that to the repo. My intention was to have it used with CI and it’s certainly how we use it.
Our Library of GitHub Actions. Contribute to cloudposse/actions development by creating an account on GitHub.
we have a lot of
auto-* type actions
Perfect place to slot in an
This actions library is great. I just created a couple days ago to do BulkRepoChanges & pipeline in azdo to be able to do a find and replace in files across all our tf module repos &/or run a cmd like pre-commit run -a….auto creates the branch, pr, etc…i was also wondering how you guys managed hundreds of repos. Digging in reading also brought to light dependabot, i haven’t seen that before…pretty cool as well.
Dev teams at 1,000+ companies like Pivotal, Instacart, and WeWork use Pull Reminders to stay on top of code reviews and ship faster.
oh ya that is nice
@Julian Gindi - nice presentation…I like the aviation angles…I have my instrument rating & loved every second of the learning process.
@IckesJ nice! Absolutely a goal of mine to finish my private and get instrument one day! Will have to talk more…