Dimensional Data

Protected branches have been around for a while, and we’ve made numerous improvements over time. We’ve added new rules to protect multiple branches and introduced additional permissions. However, it’s still challenging to consistently protect branches and tags throughout organizations. Managing scripts, cron jobs, various API calls, or third-party tooling to have consistent branch protections is not only annoying but also time-consuming. You won’t know the rules in place as an engineer until you encounter a pull request. It’s time for a new approach We’re excited to announce the general availability of repository rules. Repository rules enable you to easily define branch protections in your public repositories. With flexible targeting options, you can protect multiple branch patterns using a single ruleset. Layering makes bypass scenarios dynamic; a GitHub App can skip status checks with no additional permissions, and administrators can bypass pull requests while still requiring the important CodeQL checks to run. In line with our mission to be the home for all developers, we have integrated GitHub Repository Rules to ensure that everyone collaborating on a repository knows the rules in play for them. An overview page provides visibility on rules applicable to a branch. Relevant information about rule enforcement is available at multiple touchpoints on GitHub.com, Git, and the GitHub CLI. There are also helpful prompts on ensuring the responsible use of bypass permissions. Twilio has been using GitHub Repository Rules to balance developer experience and security. At Twilio, we value the autonomy of our engineering teams, including the ability to manage their own GitHub repositories. However, this autonomy makes compliance and security more challenging. We have successfully used GitHub Repository Rules to help us meet our compliance and security requirements while maintaining team autonomy. – David Betts, Senior Engineering Manager // Twilio GitHub Enterprise Cloud customers can enforce these rules across all or a subset of their repositories in an organization. No more tedious audits checking to see if a rule existed; now, you can ensure consistency in one location. If you’re not ready to commit to a ruleset, you can trial them in evaluate mode. Rule insights allow you to see what could happen if you dismiss stale reviews or enable linear merge history. No more guessing and no more testing in “production.” Policy enforcement is a big reason Thomson Reuters has been an early adopter of repository rules across their organization. Compliance and security controls are fundamental to keeping applications safe. At Thomson Reuters, it’s important we properly enforce these policies. With repository rules, GitHub gives us the confidence to know we are enforcing our policies across an organization effectively, keeping our applications safe for end customers. – Darren Trzynka. Senior Cloud Architect // Thomson Reuters Regarding consistency, repository rules can deliver that with new metadata rules. Branch names, commit messages, and author email addresses of the commit can be governed to help ensure organizational standards. So, set all those protected tags to use SemVer and commit messages on the Emoji-Log standard. Let’s jump in with a few scenarios where repository rules can help level up your code integrity. We’re just normal repositories. Typical rules for production repositories. Setting up repository rules can help maintain code quality, prevent mistakes, and improve collaboration. There are numerous decisions to make about the security goals of a repository, let […]

First introduced as a technical preview in June 2021, GitHub Copilot quickly emerged as the world’s first at-scale generative AI coding tool when it became generally available in June 2022. Since then, it’s played a critical role in redefining the developer experience and underscoring the impact of developer productivity and satisfaction on business outcomes. In our latest survey, we found that 92% of U.S.-based developers are already using AI coding tools both in and outside of work—which shows that most companies are already using AI, whether they know it or not. As the creators of the world’s most widely adopted generative AI coding tool, we want to empower other organizations to accelerate their innovation, while ensuring they have the transparency they need to understand and feel confident using Github Copilot. That’s why we’re launching the GitHub Copilot Trust Center. We often field questions about how GitHub Copilot protects user privacy and if the code that GitHub Copilot suggests is secure. Those questions, and many others regarding security, privacy, compliance, and intellectual property can be easily found and clearly answered on the GitHub Copilot Trust Center. When developers use GitHub Copilot, they can augment their capabilities and tackle large, complex problems in a way they couldn’t before. By following good coding practices and taking advantage of GitHub Copilot’s built-in safeguards, they can feel confident in the code they’re contributing. As organizations take note of AI’s transformative potential, GitHub aims to share guidance on how best to use these tools—and bring greater transparency to how GitHub Copilot for Business works. What you’ll find on the GitHub Copilot Trust Center AI is here to stay—and it’s already transforming how developers approach their day-to-day work. But just like any disruptive technology throughout history, AI brings important questions around its use and implications. To understand GitHub Copilot’s capabilities and proactively build policies that enable its use, organizations can reference the Copilot Trust Center to responsibly and effectively equip their developers with the AI pair programmer. Here are a few frequently asked questions to get you started: What personal data is used by GitHub Copilot for Business and how? Copilot for Business collects three kinds of personal data: user engagement data, prompts, and suggestions. User engagement data is information about events that are generated when iterating with a code editor. A prompt is a compilation of IDE code and relevant context (IDE comments and code in open files) that the GitHub Copilot extension sends to the AI model to generate suggestions. A suggestion is one or more lines of proposed code and other output returned to the GitHub Copilot extension after a prompt is received and processed by the GitHub Copilot model. Copilot for Business uses the source code in your IDE only to generate a suggestion. It also performs several scans to identify and remove certain information within a prompt. Prompts are only transmitted to the AI model to generate suggestions in real-time and are deleted once the suggestions are generated. Copilot for Business also does not use your code to train the Azure OpenAI model. GitHub Copilot for Individual users, however, can opt in and explicitly provide consent for their code to be used as training data. User engagement data is used to improve the performance of the Copilot Service; specifically, it’s used to […]

The magic of GitHub Copilot just got even better with an improved AI model and enhanced contextual filtering. These improvements give developers more tailored code suggestions that better align with their specific needs, and are available for both GitHub Copilot for Individuals and GitHub Copilot for Business. Read on to learn more about these exciting updates and how they can help you take your coding skills to the next level. Improved AI model goes beyond Codex for even faster suggestions The improved AI model behind GitHub Copilot goes beyond the previous OpenAI Codex model, offering even faster code suggestions to developers. It was developed through a collaboration between OpenAI, Microsoft Azure AI, and GitHub, and offers a 13% latency improvement over the previous model. This means that GitHub Copilot generates code suggestions for developers faster than ever, which promises to drive a substantial increase in overall productivity. Enhanced Contextual Filtering for more tailored code suggestions In addition to the improved AI model, we’ve implemented more sophisticated context filtering that takes into account a wider range of a developer’s context and usage patterns. With the update, GitHub Copilot filters prompts and suggestions more intelligently, so developers get more relevant code completions for their specific coding tasks. This has resulted in a +6% relative improvement in code acceptance rate, allowing developers to focus even more on the creative aspects of their work rather than getting bogged down in tedious coding tasks. The productivity gain also allows developers to tackle more ambitious projects and bring their ideas to life more quickly. Unlock new levels of productivity and satisfaction with GitHub Copilot The improved AI model and the new context filtering offer 13% latency improvement and 6% relative improvement in code acceptance rate, building upon the productivity gains developers have come to expect while using GitHub Copilot. With these improvements, developers can expect to stay in the flow and work more efficiently than ever, leading to faster innovation with better code. They’ll also find more satisfaction with their work, given research that shows minimizing disruptions and staying in the flow have a tangible impact on developer happiness. At GitHub, we’re committed to continuing to improve the developer experience with GitHub Copilot. We have some exciting plans in the works and will continue to share news on our blog and Changelog. Whether you’re a seasoned pro or just starting out, GitHub Copilot can help you take your coding skills to the next level–and we can’t wait to see what you’ll build with it!

Make more informed decisions about the code you use. In the rare case where a GitHub Copilot suggestion matches public code, this update will show a list of repositories where that code appears and their licenses. Sign up for the private beta today. Over the course of the last year, GitHub Copilot, the world’s first at-scale AI pair programmer trained on billions of lines of public code, has attracted more than 1 million developers and helped over 27,000 organizations build faster and more productively. During that time, many developers told us they want to see when GitHub Copilot’s suggestions match public code. Today, we’re announcing a private beta of GitHub Copilot with code referencing that includes an updated filter which detects and shows context of code suggestions matching public code on GitHub. When the filter is enabled, GitHub Copilot checks code suggestions with surrounding code of about 150 characters and compares it against an index of all the public code on GitHub.com. Matches—along with information about every repository in which they appear—are displayed right in the editor. Developers can now choose whether to block suggestions containing matching code, or allow those suggestions with information about matches. Why? Some want to learn from others’ work, others may want to take a dependency rather than introduce new app logic, and still others want to give or receive credit for similar work. Whatever the reason, it’s nice to know when similar code is out there. Let’s see how it works. How GitHub Copilot code referencing works With billions of files to index and a latency budget of only 10-20ms, it’s a miracle of engineering that this is even possible. Still, if there’s a match, a notification appears in the editor showing: (1) the matching code, (2) the repositories where that code appears, and (3) the license governing each repository. Why code referencing matters In our journey to create a code referencing tool, we discovered a few interesting things: First, our previous research suggests that matches occur in less than one percent of GitHub Copilot suggestions. But that one percent isn’t evenly distributed across all use cases. In the context of an existing application with surrounding code, we almost never see a match. But in an empty or nearly empty file, we see matches far more often. Suggestions are heavily biased toward the prompt so GitHub Copilot can provide suggestions tailor-made for your current task. That means, in an existing app with lots of context, you’ll get a suggestion customized for your code. But in an empty, or nearly empty file, there’s little to no context. So, you’re more likely to get a suggestion that matches public code. We’ve also found that when suggestions match public code, those matches frequently appear in dozens, if not hundreds of repositories. In some ways, this isn’t surprising because the models that power GitHub Copilot are akin to giant probability machines. A code fragment that appears in many repositories is more likely to be a “pattern” detected by the model—similar to the patterns we see elsewhere in public code. For example, research on Java projects finds that up to 11% of repositories may contain code that resembles solutions posted to Stack Overflow, and the vast majority of those snippets appear without attribution. Another study on Python found that many […]

Want the TL;DR, or you’ve already been using GitHub for awhile? Skip to the end for a printable checklist that you can use to ensure that you’ve covered all aspects of making your repository collaboration-ready. My daughter has a pair of pet gerbils. They’re awesome, but not the most complex creatures to care for. They need their cage cleaned occasionally, their food and water refilled, and may need a neighbor to check in on them if we’re away for a while. But someday, she may have a pet that requires more care and attention–a cat or dog perhaps, which needs to be played with and nurtured every day–so she’ll want to have a few good friends who know her pet and can be their companion whenever she’s away. And someday, she may even have a child of her own, making her connections to community and family ever more important. As the saying goes, it takes a village to raise a child. So it goes with code projects. My colleagues and I often refer to our projects as “pets” or even “children” (sometimes jokingly, sometimes obsessively). We pour a lot of our own care and attention into them, but it can be easy to forget how important the community’s contributions can be to their success. In the world of software development, collaboration can make the difference between a brittle last-minute release and a reliable, maintainable, pain-free project. Whether you’ve been coding for a day or a decade, your colleagues are there to help strengthen your work. But they can only help if you’ve given them the tools to do so. Your primary responsibility as the creator or maintainer of a repository is to ensure that others can appropriately use, understand, and even contribute to the project. GitHub is here to support that mission, but ensuring that a repository is collaboration-ready takes a bit more effort than using git clone. So read on to learn the settings, content, and behaviors that will help you succeed. 1. Repository settings The settings of your repository lay the foundation for collaboration. They determine who can see and contribute to your project, how contributions are reviewed, and what happens to those contributions once they are submitted. Properly used, they can foster an environment in which contributors across the globe will find, make use of, and help build your project. In a corporate setting, they help shift developers from a siloed way of thinking and building to a “search-first, collaborate-first” mindset. This practice, known as innersourcing, reduces redundant work and accelerates the whole company. Visibility You’re aiming to maximize contributions and reuse, but that doesn’t always mean making your repository public, especially in a corporate setting where information privacy is a consideration. You have several options available in the “Settings” tab of your repository. Public lets anyone in the world see and copy your code, and generally allows them to create issues or pull requests, so they can provide feedback about whether it works well, or even suggest (but not force) changes to improve it. This is generally great for personal projects containing no protected information (those tokens are all stored separately, right?) but only for certain “blessed” company projects. Internal is a special visibility level used by GitHub Enterprise, allowing anyone inside your organization to see […]

Today, GitHub is releasing a public beta for the new, Apple silicon powered M1 macOS larger runner for GitHub Actions. Apple silicon powered M1 macOS larger runners Apple developers require the latest chipset to take advantage of features in the latest versions of iOS and macOS. They also want increased performance by leveraging the on-chip GPU capabilities of the M1 processor. The M1 macOS runner comes with GPU hardware acceleration enabled by default. Workloads are transferred from the CPU to the GPU for improved performance and efficiency. The runner is equipped with a 6-core CPU, 8-core GPU, 14 GB of RAM, and 14 GB of storage. It can reduce build times by up to 80% compared to the existing 3-core Intel standard runner, and up to 43% compared to the existing 12-core Intel runner. How GitHub uses the M1 runner to build GitHub mobile for iOS The GitHub mobile iOS team leverages the new M1 runner for 10k+ minutes to deliver updates of the GitHub iOS app to the Apple App Store every week. The transition from the 12-core Intel runner to the M1 runner resulted in a 44% build time improvement, from 42 minutes to 23 minutes. While the time spent testing the binary remained constant for single target runs, code compilation improved by 51%, along with UI tests improving by 55% across the entire GitHub mobile test suite. The transition to the M1 runner was seamless, with updating the YAML workflow label being the only requirement to access it. However, due to differences in UI rendering between M1 Macs and Intel Macs, the team had to re-record images for snapshot tests, which compare new UI images with recorded reference images on a pixel-by-pixel basis. The M1 runner has proven to be advantageous for iOS teams, as it provides access to the VMs GPU and speeds up the App Store review process. Faster approval and publishing of apps can be achieved, which reduces the time spent on submitting to the Apple app store. How to use the runner To try the new Apple silicon macOS larger runner, update the runs-on: key in your GitHub Actions YAML workflow YAML file to target macos-latest-xlarge or macos-13-xlarge. The 12-core macOS larger runner is moving from xlarge to large, and is still available by updating the runs-on: key to macos-latest-large, macos-12-large, or macos-13-large. There is no sign-up required for the beta and the runner is immediately available to all developers, teams, and enterprises. New macOS runner pricing As part of GitHub’s continued commitment to deliver the best developer experience we are excited to share with you that we will be decreasing the price of our macOS larger runners. We understand the importance of achieving both cost-efficiency and high performance and this price decrease reflects our dedication to supporting your success. With today’s launch, our macOS larger runners will be priced at $0.16/minute for XL and $0.12/minute for large. To learn more about runner per job minute pricing, check out the docs. Additionally, if you’re interested in using larger macOS runners and understanding the difference between them and larger Linux and Windows runners, you can find more details in the “About larger runners” section of our documentation. What’s next? You can track progress towards the general availability of macOS larger runners by following this […]