#github-actions (2024-05)
Discussions related to GitHub Actions
2024-05-02
Artifact Attestations public beta Artifact Attestations public beta The post Artifact Attestations public beta appeared first on The GitHub Blog.
Dependabot pull requests jobs are now available to run on self hosted Actions runners Dependabot pull requests jobs are now available to run on self hosted Actions runners The post Dependabot pull requests jobs are now available to run on self hosted Actions runners appeared first on The GitHub Blog.
2024-05-03
2024-05-07
Actions: New region support for Azure private networking Actions: New region support for Azure private networking The post Actions: New region support for Azure private networking appeared first on The GitHub Blog.
Gah! just give me folder support for my workflows already….
2024-05-14
GitHub-hosted runners: Public Beta of Ubuntu 24.04 is now available GitHub-hosted runners: Public Beta of Ubuntu 24.04 is now available The post GitHub-hosted runners: Public Beta of Ubuntu 24.04 is now available appeared first on The GitHub Blog.
Hi everybody 
new in the community, I was making a github action workflow that executes playwright tests, but then we realized that some of the endpoints are not exposed to internet, so my challenge now is to make a workflow_dispatch in github action that can trigger a workflow in AWS codepipeline (because here the endpoints are accessible), for that also I need to send some env variables declared in the workflow to codepipeline, have you guys done something like that? any document I can read to get more insights on how to achieve my goal?
I would probably create w workflow with following steps:
• configure aws creds using this action
• trigger pipeline with aws cli and used --variables to pass some envs form gha to codepipeline
never done this, though, so might miss something
We use self-hosted GHA runners, deployed within VPCs. That way don’t have these problems.
For non EKS, we use https://github.com/philips-labs/terraform-aws-github-runner
Lastly, just last month AWS announced this, but we haven’t tried it yet. https://aws.amazon.com/about-aws/whats-new/2024/04/aws-codebuild-managed-github-action-runners/
@Erik Osterman (Cloud Posse) that sounds really interesting, sadly I haven’t done that before, thanks for sharing Erik
do you have any other doc or link with some real example I can refer to?
All of it’s documented in our paid/commercial reference architecture
Which approach is most appealing? Maybe I can link you to something public
Looks like the idea of having a self hosted runner is the better since it allows to keep everything in github actions, sounds cleaner
@Erik Osterman (Cloud Posse) BTW, I received this comment form someone in my team when I suggested using self hosted runners:
I don’t think it’s a good idea to open any sort of direct network communication between GitHub and AWS private VPCs.
I don’t think that’s a valid concern since we are already using aws credentials in github, so to me the security concerns are already being shared between github and aws, but what do you think guys I can respond to be consice and claer and get allowed
Are you free to join #office-hours ?
First problem, stop using any AWS credentials on GitHub. Use GitHub OIDC and IAM roles, so there are no hardcoded credentials.
Using CodeBuild/CodePipeline + GitHub is Identical to using GitHub + Self-hosted Runners, from a security/attack surface.
You need to test your software. Your software is on GitHub. You need to test your software on AWS where it will run. I don’t see a world (with end-to-end automation) where these two things are disjoint.
You should already have dev/staging/production, in entirely different AWS accounts.
Your CI technically, only needs access to test it in one of those accounts (or some other testing account).
Fwiw, dozens of our customers use this exact pattern, this is the first time I’ve heard the concern. Self-hosted runners is usually an enterprise requirement rather than concern.
2024-05-15
2024-05-16
New dates for Actions larger runner multi-label deprecation New dates for Actions larger runner multi-label deprecation The post New dates for Actions larger runner multi-label deprecation appeared first on The GitHub Blog.
2024-05-17
Updated dates for Actions runner using Node20 instead of Node16 by default Updated dates for Actions runner using Node20 instead of Node16 by default The post Updated dates for Actions runner using Node20 instead of Node16 by default appeared first on The GitHub Blog.
2024-05-20
Actions: Upcoming changes to GitHub-hosted macOS runners Actions: Upcoming changes to GitHub-hosted macOS runners The post Actions: Upcoming changes to GitHub-hosted macOS runners appeared first on The GitHub Blog.
2024-05-23
Anyone facing issues with Affected Stacks, seems like it is unable to get the correct componentPath, runs previously successful are failing now: Previously:
Run set +e
set +e
TERRAFORM_OUTPUT_FILE="./terraform-${GITHUB_RUN_ID}-output.txt"
tfcmt \
--config /home/runner/work/_actions/cloudposse/github-action-atmos-terraform-plan/v2/config/summary.yaml \
-owner "Org" \
-repo "aws_infra_atmos" \
-var "target:ops-logging-deploy-org_vpc_logs-bucket" \
-var "component:org_vpc_logs-bucket" \
-var "componentPath:components/terraform/s3-bucket" \
Now:
Run set +e
set +e
TERRAFORM_OUTPUT_FILE="./terraform-${GITHUB_RUN_ID}-output.txt"
tfcmt \
--config /home/runner/work/_actions/cloudposse/github-action-atmos-terraform-plan/v2/config/summary.yaml \
-owner "Org" \
-repo "aws_infra_atmos" \
-var "target:ops-logging-deploy-org_vpc_logs-bucket" \
-var "component:org_vpc_logs-bucket" \
-var "componentPath:components/terraform/" \
Which eventually leads to failure This is my step snippet:
- name: Plan Atmos Component
uses: cloudposse/github-action-atmos-terraform-plan@v2
with:
component: ${{ matrix.component }}
stack: ${{ matrix.stack }}
atmos-config-path: /home/runner/work/_temp/atmos-config