#github-actions (2023-01)

cc @matt

@jose.amengual

yes, I gave it a read

I think is a very simplistic “good enough” solution with no feedback loops except for some task status etc

in my opinion Drift detection should have an option to have more detail and historical reference of what happened etc

so in a GitOps scenario you should be able to see what happened and hopefully that is recorded in the repo too

yeah, I kinda kept it open ended with the alerting mechanism on this article. Slack, email, etc. For something more in-depth, I would use a dedicated tool, but I think for a lot of people, this and possibly cloudtrail should be a good start. Also having strict rules on how terraform code is promoted through environments should help eliminate drift

totally, your article is pretty good , and for most people this is more than enough for sure

Where I come from if from the Atlantis side ( I’m a Maintainer) and I just implemented a github action workflow similar to what you propose in the article but for a tool that already does GitOps the github action user workflow is not the best to go about it and makes unnecessary steps to be needed for implementation

Ideally the GitOps tool ( Atlantis, spacelift, TFC) should communicate back through more than one channel

and in case of finding drift it should report back in or leave a trail of what it did if autoremediation was done, in form of a ticket, PR or whatever

and hopefully the GitOps tools can have and /api/drift than can be trigger by a simple workflow(not github specific) or support multiple VCSs too

yeah, I guess hoping what’s committed to main is the desired state and if the drift is too destructive, then maybe triggering an escalation for human review

correct

Hmm i don’t think you can access custom user attributes in github

If you could, i imagine that would be through gh enterprise with a saml sso setup but even then i don’t think gh actions would have that granularity out of the box

You could use a gh action to ping your idp for a custom attribute and then allow or deny based on the value returned

I was thinking maybe at the PR level

on the payload that could be reflected

like the group the user belongs to

couldnt you do that with teams instead ?

yes you can

what problem are you trying to solve?

just an idea not a problem

take this script for example :

#!/usr/bin/env bash
atmos describe affected --ref refs/heads/main --file affected.json
stacks=""
components=""
for s in `jq -cr '.[]|.stack' affected.json|uniq`; do stacks+="${s},"; done
for c in `jq -cr '.[]|.component' affected.json|uniq`; do components+="${c},"; done

echo ${stacks%?}
echo ${components%?}


atmos atlantis generate repo-config --config-template config-1 --project-template project-1 --workflow-template workflow-1 --stacks ${stacks%?} --components ${components%?}

do you guess what it does?

(you need bash4)

that will generate an atlantis.yaml file that will only contain the affected components/projects

this limits the blast radius of the user PR against other project that should not be planned at all

oh wow very cool

cc: @Andriy Knysh (Cloud Posse) @Erik Osterman (Cloud Posse)

so the user can go in and do atlantis plan -p myproject or have autoplan enabled and it will only plan the stuff that pretends to the PR, do you see how powerful this is?

it extrapolates the complexity in this case atlantis to have to have this guardrails and brings is back to the source …..the VCS

so not imagine this:

it might be a good feature request to create the atlantis.yaml file for only stacks/components affected so you do not need to run the custom shell script e.g. atmos atlantis generate repo-config --affected

you match the user group and now you only do

for s in `jq -cr '.[]|.stack' affected.json|uniq`; do if [ $s == “.*-prod”]; then stacks+=“${s},” fi; done

( I think the syntax is wrong but you get the idea)

yes that will be really cool feature

I requested the project name to be part of the affected Json output

https://github.com/cloudposse/atmos/issues/294

I just added your suggestion

yes, we’ll add the atlantis project name to atmos describe affected - it will eliminate a lot of shell code

atmos atlantis generate repo-config --affected-only is another feature, @jose.amengual if you think it would be useful, please open another issue or add it to the one you already opened

I will open a new issue , np

https://github.com/cloudposse/atmos/issues/303 @Andriy Knysh (Cloud Posse)

thanks

good #office-hours question

note this is for GitHub Enterprise only

or so I thought…

Actually, I can’t find mention that it’s enterprise only.

the roadmap issue is tagged cloud

all for a README update

I submitted a support request

Guessing the repo was archived while the build was running. Once archived, the repo state is readonly and the state couldn’t be updated.

This repository has been archived by the owner before Nov 8, 2022. It is now read-only.

Thank you for contacting GitHub Support.
I took a look at the affected run. It seems the repository was archived before the push that triggered that workflow hence it stayed in a pending state.
This will not affect the billing since the repository has been archived by the owner.

Ya, makes sense

I didn’t know gitleaks costs money

I’ve used gitleaks locally and haven’t used their action. I never had to pay for it tho

Are you using it as a pre-commit hook?

GitHub has a paid feature for secret scanning, but it too costs money.

In my Pivotal days, we wrote our own open-source credential scanner.

It’s effectively unmaintained, the last release was over a year ago. However, if you’re keen, it may serve as an inspiration for your own project.

did any of you came across a tool that scans GHA artifacts and logs?