#release-engineering (2021-01)
All things CI/CD. Specific emphasis on Codefresh and CodeBuild with CodePipeline.
CI/CD Discussions
Archive: https://archive.sweetops.com/release-engineering/
2021-01-04
would folks be interested in a build-harness pr that runs the init logic automatically? been playing with it in my own project, and seems to work. kinda abusing the include directive
init…..as terraform init or…..
oh sorry, make init, from the build-harness bootstrap
yes that sounds good
possibly - what does it look like?
my main concern is that it should error gracefully if the user doesn’t have make
Found a bug in my patch, so not quite ready. But the user still needs make as a prereq. I’m not addressing that… Just, if you run make foo without first invoking make init then it will handle the clone for you. I should have something tomorrow. Cards on the table, it’s reasonable straightforward but may not be pretty, so definitely hoping to spark discussion and simplify logic, or clean it up or work out a use case I missed…
I’m interested in this. I’ve thought about this before and figured it was possible with some extra make-fu.
i got derailed yesterday with a customer (dang that paid work!)… trying to get back to it today…
@Erik Osterman (Cloud Posse) @Matt Gowie @jose.amengual pr open… https://github.com/cloudposse/build-harness/pull/272
2021-01-06
2021-01-07
@hairyhenderson has joined the channel
2021-01-08
2021-01-21
Thanks Erik! For those that missed it, the CircleCI+Cloudsmith+Hashicorp webinar is now available on YouTube: https://www.youtube.com/watch?v=lgapqUVobWA
2021-01-27
Hello. Does anyone use Github deployment API ?
…with #github-actions
@Igor Rodionov - I am using it since about a week for a project. We currently use the deployment api to trigger a github action that performs a deploy on the environment.
I am considering to try https://deliverybot.dev/ - however don’t have the time yet to deploy it. If anyone has experiences or alternative solutions, that would be great
TIL about make …. can’t normally override target-specific vars from envs through a sub-make:
$ cat Makefile
foo: FOO ?= foo
foo:
@echo "[$@]: FOO=$(FOO)"
test:
@echo "[$@]: FOO=$(FOO)"
@$(MAKE) -s foo
$ FOO=bar make test
[test]: FOO=bar
[foo]: FOO=foo
If you want that to work, you have to export the target-specific var:
$ cat Makefile
foo: export FOO ?= foo ## <==== only change!
foo:
@echo "[$@]: FOO=$(FOO)"
test:
@echo "[$@]: FOO=$(FOO)"
@$(MAKE) -s foo
$ FOO=bar make test
[test]: FOO=bar
[foo]: FOO=bar
I was getting ready to do something very similar…thanks for the insight
my pain, your gain! took me literally all day to figure out
of course i was starting with a much more complex Makefile, and went down a lot of weird rabbit-holes first…
i eventually found this link, which has terrible formatting and may be a copy of an original, but it talks about these kinds of gotchas… https://www.cmcrossroads.com/article/basics-getting-environment-variables-gnu-make
2021-01-28
What do you think about tagging every commit landed to master ? In other words, whenever a new commit is merged/pushed to master a new version of the app is created.
Yes. I’m pro-tagging and we are tagging every new commit in master for all infrastructure code we have where applicable whether it’s a module or a helmfile. My question was more about apps and microservices, because when it comes down to microservices developers sometimes don’t want it to be like that. I thought I read a discussion about pros and cons of tagging every commit somewhere here in Cloud Posse’s slack. However I might be wrong, probably it was elsewhere, because I couldn’t find it. That’s why I asked)
Hrmmm I know we have talked about our philosophy on it, but not necessarily in relation to micro services.
Personally I don’t see a difference.
Personally I don’t see a difference.
Neither do I.
Thanks for pointing out your docs! Haven’t seen it before. Interesting.