#release-engineering - July 2020

Anyone know if it’s possible to use github branch protections to ensure that a PR to branch-a must come from branch-b?

i’m thinking not

yes & no. You can trivially create a github action that checks the source branch and target branches.

You can fail the build if they aren't what you want them to be.

then use github branch protections to require this github action build to pass before merging..

okay, i’m with you.

I guess it’s finally time for me to explore github actions

Small one for ya - https://github.com/cloudposse/github-commenter/pull/19

Any tips how you effectively switch off some functionality on dev/staging? Like you don’t want to send emails to real users from dev and staging envs or something similar (btw there is a nice service called Mailtrap to achieve this, but sending emails is not the only case). Recently we’ve got a requirement that a certain file with a cryptic name should be created by hand on every production instance (a set of services) to be sure that production functionality can’t be accidentally activated on dev or staging and env vars are not even an option.

Anybody using SemaphoreCI? Or have opinions on it?

I am the Jenkins Master!!!!

what exactly are the limits of running self managed gitlab CE in our cloud environment?
I can’t seem to find a good document on CE vs EE

Private go modules are the devil with hosted CI services

Folks using azure devops - with the self hosted build agents, is there a way to do this (in AWS preferrably) so that the agent is created 'on demand' as part of an EC2 ASG or Fargate task? We have a few very long running, and expensive compute resource jobs currently in jenkins, i wouldn't want to just leave those instances running 24/7 if were to migrate to Azure DevOps. Their docs seem more focused on just having some permanent pool of these agents up.

Trying to decide where to store helm values and ci/cd information for charts; Am thinking deploy to staging on merge to master and deploy to prod on github release, but that feels cumbersome with a monorepo due to having to filter on paths and put names in releases, but it feels a little wrong to have an entire repo with just 2 files in it for helm deploys.