The GitHub Actions extension for VS Code is now in public beta. This extension includes rich editing features, such as syntax validation and autocomplete, making workflow authoring and editing faster and easier. Developers will also be able to view workflow runs, inspect logs, and trigger re-runs directly from VS Code.
The new code scanning tool status page allows users to view the status of CodeQL and other code scanning tools.
The page shows all the tools that are enabled on the repository and provides information about their setup types, configurations, and any relevant failures or warnings. If a tool is not working as expected, this is a good place to start troubleshooting the issue.
The page indicates three possible statuses for the tool: all configurations are working, some need attention, and some are not working.
Code scanning needs to have received at least one analysis for the default branch to provide a tool status. Only the status of the default branch is reported.
The page shows the latest state of all analysis configurations for the tool. For instance, if you created two separate workflows to scan two distinct parts of the repository independently, the page displays the most recent state of the tool by combining the statuses of both.
The page structure
For each tool, the page provides actionable information about misconfigurations and errors, the number of scanned files per language, the setup types and configurations, the list of rules the tool checks against, and detailed CSV reports.
Error messages
To help you with debugging, the tool status page shows error messages gathered from multiple code scanning system components during tool setup and analysis execution. These include errors from CodeQL, code scanning workflows, SARIF upload limits, and the internal code scanning system.
Third party code scanning tools are not yet able to deliver tool related errors to the page. In the future, these tools will be able to submit error messages to code scanning via SARIF uploads.
The section helps you determine whether code scanning tools are operating correctly on your repository and only shows information about languages supported and analysed by the tool while ignoring languages that are present in the repository but are not supported or being analysed by the tool.
This section is not yet displayed for third party code scanning tools. In the future, third party tools will be able to submit error messages to code scanning via SARIF uploads.
Delivery dates
This has shipped to GitHub.com and will be available in GitHub Enterprise Server 3.9.
We improved the color contrast of our default light and dark themes on github.com, making them accessible to all users. These changes were made to Primer, GitHub's Design System, as part of our commitment to making GitHub inclusive to all developers. Visit accessibility.github.com for more information.
The VS Code light and dark themes will also be updated to match these changes.
✕
Wait! Don't Go Yet 🚀
Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!
Educators using GitHub Classroom can now optionally set a assignment deadline to be a "hard cutoff." If you use a cutoff date, students will lose write access to their assignment repositories after the cutoff date has passed.
You can grant individual students and groups extensions to allow them more time to submit an assignment.
The assignment dashboard view is now updated to better indicate whether a student has committed to their repository on-time (before the deadline), late (after the deadline), or both. You can easily filter the dashboard view on these states, and quickly click through to the latest on-time and late commits of a student's repository.
Addressing a big ask from students, they can now click a button in their assignment README to view the deadline of the assignment at any time.
We've recently released a few improvements to the slide-out enablement panel on the security coverage page in security overview:
Active committers for the repository are now visible, providing insight into the number of Advanced Security licenses being utilized. For repositories where Advanced Security is not enabled, the number indicates the number of licenses required to enable the feature.
Unsaved changes are now clearly labeled with a "Modified" tag. Additionally, the "Save security settings" button now displays the total number of enablement changes being made.
While a security feature is being enabled, the coverage page will show a status of "Updating…" to keep you informed of the ongoing process.
These improvements have shipped to GitHub.com and will be available in GitHub Enterprise Server 3.9.
Organization owners can now automate the approval and auditing of fine-grained personal access tokens (PATs) in their organization using a GitHub app. New APIs and webhook events allow a GitHub app to be notified of new PAT requests in an organization, review the request, and then approve or deny the PAT. They also provide a view of all approved fine-grained PATs for an organization, with the ability to revoke their authorization as well. These APIs and events are part of the ongoing fine-grained PAT public beta that launched last year.
Details included in the webhook event and API listings include the repositories and permissions requested, the expiration time of the token, and the user's explanation for what they plan to do with the PAT. The personal_access_token_request events are generated when a request is created, approved or denied by an administrator or application, or cancelled by the requesting user.
Only a GitHub app is able to call these APIs, either acting on its own or on behalf of a signed-in organization administrator.
The organization_personal_access_tokens permission is needed to manage the active tokens, while the organization_personal_access_token_requests permission enables the app to recieve webhooks about requests and call the request management APIs.
Organizations must have the personal access token approval flow enabled in order to manage these requests, otherwise fine-grained personal access tokens are automatically approved for the organization (which generates a personal_access_token_request: approved event).
Enabling caching by default has demonstrated improved workflow performance, and can reduce build times by 20-40% for repositories with dependencies greater than 100 MB! This change has been made to the latest setup-go Action(V4). Developers no longer have to specify the cache: true parameter in their YAML file to obtain the benefits of caching. For more information on building, testing, and caching dependencies with Go, check out the docs here!
✕
Wait! Don't Go Yet 🚀
Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!
In addition to Ubuntu & Windows, GitHub Actions now attaches a SBOM (Software Bill of Materials) to hosted runner image releases for macOS. In the context of GitHub Actions hosted runners, an SBOM details the software pre-installed on the virtual machine that is running your Actions workflows. This is useful in the situation where there is a vulnerability detected, you will be able to quickly tell if you are affected or not. If you are building artifacts, you can include this SBOM in your bill of materials for a comprehensive list of everything that went into creating your software.
To check out the new files, head over to the runner-images repository release page now or check out our docs for more information.
✕
Wait! Don't Go Yet 🚀
Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!
We're thrilled to introduce the GitHub Classroom CLI extension for the GitHub CLI, designed to simplify the lives of teachers everywhere. With this powerful new tooling, teachers can create their own personalized workflows, as well as streamline any custom solutions they've already built.
To get started, ensure you have the GitHub CLI installed, then install the extension with the following command: gh extension install github/gh-classroom
Command your Classroom
The GitHub Classroom CLI extension provides a suite of commands to help you navigate your classrooms and assignments with ease. Here's a quick overview of its capabilities:
gh classroom list: List all your unarchived classrooms
gh classroom view: Show the details of a classroom, such as its name, description, URL, and roster
gh classroom assignments: Display a list of assignments for a classroom
gh classroom assignment: Show the details of an assignment, such as its title, type, deadline, starter code URL, and number of submissions
gh classroom accepted-assignments: List your students' accepted assignments
gh classroom clone starter-repo: Clone the starter code for an assignment
gh classroom clone student-repos: Clone all your students' submissions for an assignment (a scriptable alternative to the Classroom Assistant desktop application)
To target a specific classroom, use the -c flag with each subcommand (retrieve a classroom's ID through selecting it in gh classroom ls or gh classroom view). In the absence of the -c flag, an interactive picker navigable with arrow keys will help you select the target classroom.
This collections of subcommands marks the beginning of our journey to deliver power features that save you time and enhance your workflows.
You can report issues or request features on our public repository, where we look forward to open sourcing the code in the coming weeks.
GitHub Security was notified about an issue where private issue and pull request titles would be displayed in search results. Our Security team investigated potential instances and determined that this only occurred when the author of the commit was authorized to view the issue or pull request and the commit was titled as a link to the private issue or pull request. Additionally, this only happened while using the new code search (beta). This issue was introduced when the new code search (beta) launched and was fixed on January 17, 2023. As this issue has been addressed, there is no further action that is required by any user.
✕
Wait! Don't Go Yet 🚀
Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!
Today we are announcing the general availability (GA) of roadmaps in GitHub Projects! 🎉
🗺 Roadmaps for all
Since we announced the public beta of roadmaps earlier this year, we've shipped exciting updates that allow you to quickly adjust your roadmaps and visualize and track work with important milestones and dates, alongside lots of bug fixes and improvements. Thank you to everyone who participated in the beta for all of the feedback! 💖
To get started with a roadmap, select the roadmap layout when creating a new project, or create a new roadmap in an existing project by selecting "Roadmap" in the view options menu.
📍 Track important dates with roadmap markers
If you are using milestones to track progress for larger bodies of work, iteration fields to plan out your weeks and months, or date fields for important deadlines, roadmap markers help you and your team keep track of important upcoming dates. Configure these from the Markers menu to make sure all of your important dates are visible on your roadmap.
⚡ Quickly adjust roadmap items
Plans often change, and so can your roadmaps! Quickly make edits to your roadmap items by dragging and dropping them to a different date or iteration, or moving them to another status or team.
✨ Other enhancements
Create a roadmap from the Select a template dialog when creating a new project
Edit item titles directly from the table
Use arrow keys for navigating table items
Use the floating + Add items bar when there is no 'Group' field selected
Resize the table using keyboard navigation
✍ Tell us what you think!
We want to hear from you! Be sure to drop a note in the discussion and let us know how we can improve. Check out the documentation for more details.
✨ Bug fixes and improvements
Enabled vertical scrolling in the Workflows page
Fixed a bug where the New column menu was appearing again when adding a new board column
Fixed a bug where the Add selected items button was out of view in the bulk-add pane
Moved reactions on issues and pull requests to the bottom left of the comment box, making it easier to respond after reading and creating consistency with discussions
(Tasklists Private Beta) "Convert to Issue" is now more discoverable on the tasklist item versus in the three-dot menu
(Tasklists Private Beta) Fixed a bug where some repository names were getting cut off
See how to use GitHub for project planning with GitHub Issues, check out what's on the roadmap, and learn more in the docs.
✕
Wait! Don't Go Yet 🚀
Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!
GitHub blocks branch and tag names which begin with refs/.
Under the hood, all Git refs begin with a prefix (refs/heads/ for branches and refs/tags/ for tags). In typical use, though, users rarely see these prefixes, so they're silently handled by GitHub, the Git client, and other tools. When a similar string is used as the beginning of the visible part of the branch or tag name, this results in ambiguity: did the user intend refs/heads/feature or refs/heads/refs/heads/feature? In nearly all cases, refs/ in front of a branch or tag name is accidental and becomes a problematic surprise later.
This change blocks new introductions of such names. Repositories with existing branches named this way can still push updates to those branches.
✕
Wait! Don't Go Yet 🚀
Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!
Onboard a repository to default setup: gh api -X PATCH /repos/[org-name]/[repo-name]/code-scanning/default-setup -f state=configured
Specify which CodeQL query suite to use in the default setup configuration: gh api -X PATCH /repos/[org-name]/[repo-name]/code-scanning/default-setup -f query_suite=extended
View the current default setup configuration for a repository: gh api /repos/[org]/[repo-name]/code-scanning/default-setup
Offboard a repository from default setup: gh api -X PATCH /repos/[org-name]/[repo-name]/code-scanning/default-setup -f state=configured
When you onboard a repository via the API, you will recieve a workflow run ID which can be used to monitor the setup progress. This can be used to see the status and conclusion of the run: gh api repos/[org-name]/[repo-name]/actions/runs/[run-id] --jq '.status, .conclusion'
Restrict token access to specific packages and/or scopes
Grant tokens access to specific organizations for org and user management
Set a token expiration date
Limit token access based on IP address ranges
Select between read and/or write access for the token
We recommend using granular access tokens with least privileges for automating your publishing and org management activities. You can allow your package to be published without 2FA using granular access tokens from your trusted CI/CD systems. Additionally, you can also configure your package to require 2FA when publishing from a local machine to defend against account hijacking.
Read more about creating a granular access token here.
✕
Wait! Don't Go Yet 🚀
Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!
You can now enable the "security extended" query suite for repositories using code scanning default setup with CodeQL. This query suite can be selected during set up, or changed at any time by viewing and editing the CodeQL configuration.
Code scanning's default query suites have been carefully designed to ensure that they look for the security issues most relevant to developers, whilst also minimizing the occurrence of false positive results. However, if you and you developers are interested in seeing a wider range of alerts you can enable the security extended query suite. This suite includes the same queries as in the default query suite, plus:
extra queries with slightly lower severity and precision.
extra experimental queries.
If you enable the security extended suite you may see more CodeQL alerts in your repository and on pull requests. For more information, see "About code scanning alerts".
Enabling CodeQL analysis with code scanning default setup for eligible repositories in your organization is now as easy as a single click from the organization's settings page or a single API call.
You can use code scanning default setup to enable CodeQL analysis for pull requests and pushes on eligible repositories without committing any workflow files. Currently, this feature is only available for repositories that use GitHub Actions and it supports analysis of JavaScript/TypeScript, Python and Ruby. We plan to add support for additional languages soon.
To help you identify which repositories are eligible for the "enable all" feature, two new security coverage filters have been added:
code-scanning-default-setup: returns a list of enabled, eligible or not eligible repositories
advanced-security: returns a list of repositories with GitHub Advanced Security enabled or not enabled
This feature has been released as a public beta on GitHub.com and will also be available as a public beta on GitHub Enterprise Server 3.9.
We announced two weeks ago that we are changing how you receive notifications for secret scanning alerts. From today, those changes are in effect.
What action should I take?
If you are a repository administrator, organization owner, security manager, or user with read access to secret scanning alerts:
Watch your repositories of interest by choosing "All activity" or "Security alerts." This helps you choose what events GitHub will notify you about.
In your user notification settings, you must choose "Email" in the "Watching" section. This tells GitHub how to notify you. Secret scanning only supports email notifications at this time.
If you're a commit author:
As long as you are not ignoring the repository in your watch settings, commit authors always receive notifications for new secrets that are leaked. This means you receive a notification for any secret committed after an initial historical scan has run on the repository.
Code scanning is now using a new way of analysing and displaying alerts on pull requests. The change ensures code scanning only shows accurate and relevant alerts for the pull request.
Previously, code scanning presented all alerts unique to the pull request branch, even if they were unrelated to the code changes the pull request introduced. Now, the tool reports only alerts inside the lines of code that the pull request has changed, which makes it easier to fix these contextualised alerts in a timely manner.
In addition, code scanning will no longer show fixed alerts on pull requests. Instead, you can check whether an alert has been fixed by your pull request on the Security tab of the repository by using search filters: pr:111 tool:CodeQL. If you fix an alert in the initial commit in the pull request, it will not be present on the PR branch.
This has shipped to GitHub.com and will be available in GitHub Enterprise Server 3.10.
The "Require SSH certificates" policy now allows GitHub apps to call Git APIs using a user-to-server token, bringing them up to parity with OAuth app support.
The SSH certificate requirement mandates that users in your organization call Git APIs using an SSH certificate issued by your organization, in place of their own SSH key or a PAT.
To support automation, it has an exception in place for OAuth apps and GitHub app server-to-server tokens, which allows applications you've approved to call Git APIs for your organization.
With this change, we are extending that exception to GitHub app user-to-server tokens, for when a user has signed into a GitHub app that's installed in your organization.
This change also applies when the enterprise-level setting requires SSH certificates across all organizations in the enterprise.
