#github-actions (2023-09)

Dual Static IP ranges for GitHub-hosted Larger runners Dual Static IP ranges for GitHub-hosted Larger runners The post Dual Static IP ranges for GitHub-hosted Larger runners appeared first on The GitHub Blog.

GitHub Actions – Updates to GITHUB_REF and github.ref GitHub Actions - Updates to GITHUB_REF and github.ref The post GitHub Actions – Updates to GITHUB_REF and github.ref appeared first on The GitHub Blog.

Increased Concurrency Limit for GitHub-Hosted Runners Increased Concurrency Limit for GitHub-Hosted Runners The post Increased Concurrency Limit for GitHub-Hosted Runners appeared first on The GitHub Blog.

Migrate Bamboo and Bitbucket Pipeline to GitHub Actions Migrate Bamboo and Bitbucket Pipeline to GitHub Actions The post Migrate Bamboo and Bitbucket Pipeline to GitHub Actions appeared first on The GitHub Blog.

GitHub Actions – Force cancel workflows GitHub Actions - Force cancel workflows The post GitHub Actions – Force cancel workflows appeared first on The GitHub Blog.

GitHub Actions: Transitioning from Node 16 to Node 20 GitHub Actions: Transitioning from Node 16 to Node 20 The post GitHub Actions: Transitioning from Node 16 to Node 20 appeared first on The GitHub Blog.

Hey I’ve been looking at dependency management and stumbled on tools like dependabot/renovate. However, we use sonarcloud (SAAS) for code-quality, static code analysis. I’d like to ask if there is a way in sonarcloud for performing dependency management?? I’d be more interested to know how it can be enforced on the repos, like dependabot / renovate. I am not very sure if sonar is right tool for the job, just trying best to avoid a tool sprawl.

Please point me to the right channel if it’s not

Hello, Q re the GH action workflows. Looking at the workflow triggers: event based, scheduled, and manual(workflow_dispatch), noticed that scheduled and manual based triggers have a requirement that the workflow file is on the default branch which makes its development comply with the branch protection rules(require approvals, etc). But from the looks of it, it isn’t the case with event based triggers. Just thinking about the security implications. Thinking of a scenario where folks can create a branch “x” and setup a workflow with a trigger on push to branch “x”, and the workflow can access the repo secrets and the underlying runners ie you can trigger workflow from arbitrary branches, and can have unreviewed code running arbitrary releases. To add, the above is in reference to a private repo with GH Team license. wanted to check if i am missing anything, or if there is a workaround for the above issue, or if there is a repo/org level setting that should just do the trick.

Changes to token permission on packages Changes to token permission on packages The post Changes to token permission on packages appeared first on The GitHub Blog.