GitHub Actions Importer now supports migrations from Bitbucket, Bamboo Server, and Bamboo Data Center. Companies using those tools can plan, test, and automate the migration of pipelines to GitHub Actions more easily than ever before.
GitHub Actions Importer is available via the GitHub CLI or IssueOps. To get started, please visit our docs. For questions and feedback, check out the GitHub Actions Importer community.
GitHub-hosted runners now support up to 1000 concurrent jobs for our 4 – 64 vCPU runners, enhancing their capability to handle large-scale CI/CD workloads.
Our runners are designed to automatically scale to meet your needs. The concurrency limit feature allows users to specify the maximum number of jobs that can run simultaneously to execute Actions workflows. Previously capped at 250, we've made backend improvements to now support a maximum of 1000 concurrent jobs for runners within the 4-64 vCPU range for Windows and Linux operating systems.
Enterprise or organization administrators can set this concurrency limit under the Auto-scaling setting. GitHub-hosted runners with 4 or more vCPUs are available on both the GitHub Team and Enterprise plans.
If you have any feedback to help improve this experience, be sure to post it on our GitHub Community Discussion.
We have implemented a fix so that GITHUB_REF and the github.ref context value return a fully-formed ref (e.g – refs/heads/main) when a workflow is triggered as a result of a pull request being merged. This change only impacts a small subset of workflows that trigger as a result of a pull request closing after being merged and that make use of GITHUB_REF or github.ref.
Previously, GITHUB_REF and github.ref were incorrectly returning a shortened ref (e.g. – main). These should always return a fully-formed ref regardless of the scenario.
Please visit our documentation for more details about using Actions context and variables.
For questions, visit the GitHub Actions community.
To see what's next for Actions, visit our public roadmap.
GitHub-hosted larger runners now support dual IP ranges when configured with Static IPs for the GitHub Enterprise Cloud plan.
Static IP enables Enterprise Cloud customers to choose whether a static IP address range will be assigned to their larger runner instances. This provides a fixed IP address range that can be added to your allow list for access to internal systems and can be used in conjunction with GitHub’s IP allow list to enable hosted actions runners and IP allow listing at the same time.
With dual IP ranges, larger runner instances will now receive two IP ranges instead of a single range. This enables runners to scale beyond the previously existing 500 concurrency limit. Additionally, the two IP ranges are created in different geographical locations, providing resiliency against regional outages.
For newly created larger runner instances with the Static IP feature, 2 IP ranges will be assigned by default going forward and no additional action is required.
For existing larger runner instances that have Static IP configured:
You can learn more about the Static IP feature by heading over to documentation. If you have any feedback to help improve this experience, be sure to post it on our GitHub Community Discussion.
Enterprise Managed User namespace repositories were previously able to use GitHub-hosted Actions runners outside of the owning enterprise's entitlements. This was not an intentional configuration. Today we have disabled the ability for EMU user namespace repositories to use GitHub-hosted runners.
For customers using inner source workflows we recommend forking from an organization owned repository into your user namespace. You may then open a pull request back to the upstream repository and actions workflows will run as usual within the context of that organization and enterprise.
Learn more about enabling private repositories to run actions workflows from forks.
GitHub Actions asks customers to review their network allow list for self-hosted runners according to the requirements in our documentation.
Network access to GitHub's *.actions.githubusercontent.com is essential for the self-hosted runners. Requiring wildcard access allows GitHub Actions to be flexible moving forward as we improve the service. Customers that do not allow wildcard access risk having interruptions in their GitHub Actions usage as we start enforcing this requirement on September 12, 2023. Please reach out to the customer support if you have limitations with configuring wildcard access in the on-premises firewall solution.
Learn more about GitHub Actions self-hosted runners.
For questions, visit the GitHub Actions community.
To see what's next for Actions, visit our public roadmap.
With the Repository Actions Runners List, you can now view all available runners in the Actions tab of a repository. This feature is now in public beta and will be gradually released in the upcoming weeks.
The runner types listed include Standard GitHub-hosted, Larger GitHub-hosted (for faster builds), Self-hosted, and Scale-sets.
For some benefits of using the Repository Actions Runners List:
repo:write access can now view runner options without needing to rely on internal documentation or contacting a Repo admin or an Organization owner for runner label names.To access the Repository Actions Runners List:
Note: Enterprise and Organization owners can also create new runners from this page from the “New runner” button.
This feature is available to users with:
Note: This feature is not currently available to users in Organizations on the GitHub Enterprise Server and Legacy plans, or Enterprise Managed Users.
If you have any feedback to help improve this experience, be sure to post it on our GitHub Community Discussion.
GitHub environments can be configured with deployment branch policies to allow-list the branches that can deploy to them.
We are now security hardening these branch policies further by blocking runs triggered from forks with branches that match the protected branch name. We are also preventing tags with the same name as a protected branch from deploying to the environments with branch policies around protected branches.
Learn more about configuring environments with deployment protection rules to set up rigorous and streamlined guardrails for your deployments.
For questions, visit the GitHub Actions community.
To see what's next for Actions, visit our public roadmap.
Support for migrating Jenkins Scripted Pipelines to GitHub Actions is now available as a private beta! If you use Scripted Pipelines in your Jenkins instances, you can now automate the migration of your pipelines to GitHub Actions using GitHub Actions Importer.
To get started, please reach out to your GitHub account manager or contact our sales team! For questions and feedback about the private beta, please visit the GitHub Actions Importer community.
We will be moving the private beta of required workflows on GitHub Actions to Repository Rules to give organization administrators a powerful way to protect their repositories with added feature benefits including unified configuration, dry running workflow rules, branch targeting, and a consistent UI experience.
Starting September 20th, 2023, users can configure their workflows using rulesets in order to run and pass in selected repositories before merging their code. On October 18th, users will no longer be able to access Actions Required Workflows and must use rulesets in its place.
Existing Actions Required Workflows private beta users will continue to have access until October 18th, 2023, allowing them time to adapt to the forthcoming changes. During this transitional period, users will maintain their existing workflows without disruption. This ensures that organizations can smoothly navigate the migration process, avoiding any abrupt disruptions to their current code merging practices. Here’s a quick overview of the events leading up to the move.
Leading up to October 18th:
After October 18th:
To learn more about how Repository Rules can help control how people can interact with branches, visit our documentation.
Today, we are announcing public beta of the new experience for deployments across environments.
Developers and DevOps managers can now view and track the full history of deployments in a repository or filter them across environments to:
Learn more about viewing deployments in your repository through our documentation and watching this video.
For questions, visit the GitHub Actions community.
To see what’s next for Actions, visit our public roadmap.
On October 11, 2022, we annouced plans to deprecate the save-state and set-output workflow commands on May 31, 2023. We have since decided to postpone the removal given the amount of usage we are still seeing with these commands.
Workflows using save-state or set-output in their workflows will continue to work as expected, however, a warning will appear under annotations indicating the planned deprecation. We recommend customers using these commands to upgrade their workflows to use environment files.
For more information on environment files, please check out our documentation. To see what's next for Actions, visit our public roadmap.
Node12 has been out of support since April 2022. As a result we started the deprecation process of Node12 for GitHub Actions by migrating all actions to run on Node16 on June 14th.
We have seen no major issues reported and a minimal number of people opted out of the forced upgrade to Node16. Given this, we will remove Node12 from the Actions runner on the 14th of August 2023.
For Actions maintainers: Update your actions to run on Node16 instead of Node12 (Actions configuration settings)
For Actions users: Update your workflows with latest versions of the actions which runs on Node16 (Using versions for Actions)
GitHub Actions – OpenId Connect (OIDC) integration with AWS is now optimized to avoid pinning any intermediary certificate thumbprints.
While configuring GitHub as an OIDC IdP (ID Provider), AWS now secures communication by trusting GitHub Actions’s trusted root certificate authorities (CAs) instead of using a certificate thumbprint to verify GitHub’s IdP server certificate.
This will address and avoid any issues caused due to pinning certificate thumbprints while authenticating from GitHub to AWS using OIDC. No action is needed for GitHub customers.
Auto-scaling self-hosted runners using the Actions runner controller and runner scale sets is now in generally avaliable.
Learn more about scalling self hosted runners and share your feedback with us in the Community Discussion!