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.
What would you do with twice the memory on your computer? How about 30% better CPU performance?
Over the past six weeks we’ve upgraded underlying infrastructure for Codespaces, migrating from Intel to AMD based CPUs, which boast improved specs.
As of today, 4-core and higher Codespaces now include twice the RAM, and 30% better CPU performance, at no additional cost to you. You now get snappier performance and more room for your processes to stretch out without having to lift a finger. We’ll be rolling out the same upgrade for the 2-core Codespaces in a matter of days.
If you’re using an 8-core machine because you need the RAM, now you can save cost by backing that down to a 4-core machine so you get twice the bang for the buck. Same goes for scaling down from 4 to 2 cores, and so on. Because free usage of GitHub Codespaces is calculated by cores per hour, using a smaller machine will also give you more free coding hours.
Now your GitHub Codespaces cloud dev environment builds, tests, and shares your running application faster than ever, at the same price.
Note: this release does not affect the machines used in the generation of Codespaces prebuilds.
Give ‘em a spin! https://github.com/codespaces
You can now use the REST API to request a CVE identifier for your repository security advisories.
Learn more about repository security advisories and CVE identification numbers.
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.
As of August 17, 2023, Dependabot will no longer support Python 3.6 or 3.7, which have reached their end-of-life. If your code uses these versions, Dependabot will no longer be able to open pull requests in your repository and will log errors. Update to at least Python 3.8 to ensure your code is secure and Dependabot can still run.
View the official release cycle for Python for more information on supported versions.
pnpm is now fully supported by dependency graph, Dependabot alerts, and Dependabot security updates! If you manage your Node.js dependencies with the pnpm package manager, you can now receive and fix alerts about security vulnerabilities in those dependencies. To use this, enable Dependabot Security Updates from the repository settings page on the code security and analysis tab.
To read more about how to use Dependabot and dependency graph, you can read our documentation here
In early July, GitHub announced a new rate limit was coming for the audit log API endpoints. Starting today, each audit log API endpoint will impose a rate limit of 1,750 queries per hour per user, IP address, enterprise, or organization. This is higher than the previously stated change to 15 queries per minute, in order to allow integrators more time to adjust workflows and scripts which programmatically query the audit log API. We intend to enforce a limit of 15 queries per minute on or after November 1st, 2023.
This rate limit will be enforced on each combination of an individual user, IP address and entity path (/orgs/<org_name>/audit_log or /enterprises/<enterprise_name>/audit_log) independently.
To adapt to these changes and avoid rate limiting, programs or integrations querying the audit log API should query at a maximum frequency of 1,750 queries per hour. Additionally, applications querying the audit log API should be updated to honor HTTP 403 and 429 responses to dynamically adjust to the back-pressure exerted by GitHub.
For additional information, please consult our documentation on handling rate limits for requests from personal accounts and rate limits for GitHub Apps. Alternatively, enterprises seeking access to near real-time data should consider streaming your enterprise audit log.
Dependabot can now open pull requests to update your Swift dependencies. In June, support for Swift advisories in the Advisory Database and Dependabot alerts was released. Dependabot will now be able to open pull requests to fix related alerts, and you will also be able to configure scheduled updates for your dependencies via dependabot.yml.
For more information on how to configure Dependabot updates, please view our documentation here: https://docs.github.com/en/code-security/dependabot
As part of the two-factor authentication requirement program on GitHub.com, the People pages of enterprises and organizations have been updated to include the 2FA requirement status of members and collaborators. As an administrator, you can see which of your users have not yet enabled 2FA but are required to do so because of an action they have take in one of your organizations, or elsewhere on GitHub.com.
A clock icon will appear as a user's 2FA status will show if the user is required to enable 2FA. When the icon is red, they are past the due date for enabling 2FA, and are at risk of being blocked from accessing GitHub.com until they enable it. Clicking the clock icon will display the user's enrollment date.
You can filter the UI to show only users who have a pending requirement. Enrollment dates are also now included in the CSV and JSON downloads of enterprise and organization memberships.
To learn more about the 2fa enrollment program, see our blog post with more details. For information about viewing your members, see the organization and enterprise documentation.
Organization owners and security managers can now view metrics associated with push protection usage across their organization.
The overview shows a summary of how many pushes containing secrets have been successfully blocked across the organization by push protection, as well as how many times push protection was bypassed.
You can also find more granular metrics, including:
These metrics are found under the Security tab of your organization and are based on activity from the last 30 days.
Code scanning default setup is now available for Swift analysis with CodeQL! Default setup now supports all CodeQL supported languages at the repository level. This includes JavaScript/TypeScript, Ruby, Python, Go, Java, Kotlin, C/C++, C#, and Swift. We're working to support enabling code scanning at the organization level for all CodeQL languages soon.
Default setup automatically detects the languages used in a repository, and automatically analyzes JavaScript/TypeScript, Ruby, Python, and Go. You can also optionally customize the configuration to analyze Java/Kotlin, C/C++, C# and Swift. The configuration can be viewed and edited at any time, during or after set up. You can also use the REST API to include languages in the default setup configuration.
Java, Kotlin, C/C++, C# and Swift are not automatically included in the default setup configuration because they often require more advanced configuration. Code written in these languages needs to be compiled in order for CodeQL analysis to proceed. CodeQL will attempt to build your code automatically but may fail if your code requires bespoke build steps.
If a language fails in default setup, you will see an error message on the repository's settings page, in the code security and analysis section. To resolve the situation you can:
yml file and allows you to provide the build information required for the CodeQL analysis to succeed.For more information, see the documentation for when a particular language is causing default setup to fail. For more information on code scanning default setup, see Configuring code scanning automatically.
You can now use the REST API to get global security advisories from the Advisory Database. This makes it easy to get access to the Advisory Database's free, open source list of actionable security advisories and CVEs which include machine readable mappings to the ecosystem, package name, and affected versions of impacted software.
Learn more about GitHub's global security advisories and the Advisory Database.
Today's Changelog brings you board swimlanes and the ability to create issues in repository groups!
You can now configure swimlanes on your boards by selecting a Group by field from the view configuration menu. This allows you to break up your items by different workstreams, team members, or priorities, similar to groups on tables and roadmaps. Drag and drop your items between columns and groups to quickly make adjustments, or add a new item directly.
You can now create issues when grouped by Repository on the table and roadmap layout. Click Create new issue or start typing the title to get started.
See how to use GitHub for project planning with GitHub Issues, check out what's on the roadmap, and learn more in the docs.
Questions or suggestions? Join the conversation in the community discussion.
CodeQL is the analysis engine that powers GitHub code scanning for over 100,000 repositories. We continuously improve our analysis capabilities, language support and performance to help open source developers and enterprises catch vulnerabilities before they make their way into production code. CodeQL is also an instrumental tool for the security researcher community and was used to identify 36 new CVE.
We release updates and improvements for CodeQL on a regular basis. We don’t get to call out all the improvements, but we want to highlight some of the most important updates we’ve shipped for CodeQL in the first half of the year:
These features have been shipped across multiple versions of CodeQL from 2.12.0 up to 2.14.0, which are shipped with GHES 3.9 and upcoming 3.10. All users of CodeQL code scanning on GitHub.com automatically benefit from the latest improvements.
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.
Starting today, publishing with provenance is restricted to public source repositories only. Private source repositories are no longer supported for use with provenance for public packages.
As announced on July 11, 2023: npm will verify the linked source commit and repository when users view a package's provenance information on npmjs.com. If the linked source commit or repository cannot be found, an error will be displayed. This can occur if a repository is deleted or if it is made private.
Read more about viewing npm provenance and publishing with provenance.
GitHub Codespaces has introduced new access and ownership settings, providing organizations more granular control over which members and outside collaborators are able to create codespaces on organization-owned private and internal repositories.
Owners of organizations on the Team or Enterprise plan can now select which of their organization's members or collaborators are allowed to use GitHub Codespaces on organization-owned private and internal repositories. In order to use GitHub Codespaces, an organization member or collaborator will need explicit access to GitHub Codespaces and either write or fork permissions on the repository.
Any members or collaborators not explicitly granted access will not be allowed to use GitHub Codespaces within the organization's private or internal repositories. Those members or collaborators may still use codespaces on public repositories owned by the organization, like any other GitHub user.
Additionally, organization administrators can select whether member or collaborator codespaces fall under organization or user ownership. Codespaces ownership dictates who pays for a codespace, which policies are applied, and where audit logs from codespace usage are sent. For organization owned codespaces, the organization pays for the codespace, organization policies apply, and the logs are sent to the organization. For an organization to own any codespaces, the organization administrator will need to set a spending limit in order to enable GitHub Codespaces within their organization. Enterprise Managed Users are not able to create user owned codespaces because their usage must be paid for by the enterprise.
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.
Repository rules are now generally available on GitHub.com.
Repository rules allow you to easily govern protections for branches and tags on your repositories. Repository collaborators also gain access to see what rules are in place via the Web, git client, and the GitHub CLI.
For GitHub Enterprise Cloud customer, you gain the ability to enforce branch and tag protections across repositories in your organization. As well as insights on rule enforcement, evaluation mode to test rules before enforcing them and governance around commit messages.
Check out the blog post to learn more about repository rules. And if you have feedback, please share and let us know in our feedback discussion.
Today's Changelog includes updates to project templates, a pinned item side panel, and pull request support in tasklists!
Since we announced the public beta of project templates for organizations, we've made improvements to what is included in a template. Any configured workflows (other than the Auto-add to project workflow), project insights, and custom fields for draft items are now included when you use a project template or make a copy of a project.
Select a template when creating a new project to see a preview of what is included.
As we continue to build out more functionality for project templates we would love your feedback and to hear more about your experiences and requests. Check out the documentation for more details.
You can now pin the item side panel in your project by selecting the pin icon in the top right corner. This allows for triage mode where you can interact with the project view while an item remains open in the side panel.
Tasklists now support pull requests as items and you can create tasklists inside of pull requests! If you have already been putting tasklists into pull requests only to have them fail on you, failure no more. ✨
We've also made the following improvements to tasklists:
Tracked byYou can now reorder your custom fields in the project settings by dragging and dropping them in the list to update the order that they appear in the item side panel and on the issue page. Once you've rearranged your fields, open an issue in the side panel to see your changes!
See how to use GitHub for project planning with GitHub Issues, check out what's on the roadmap, and learn more in the docs.