Editor Tools - page 2


Bringing checks and statuses to GitHub for Visual Studio

With the release of GitHub for Visual Studio 2.5.5, pull requests now support checks and statuses.

Checks and statuses—like continuous integration builds or deployment services—determine if the conditions set for a repository are met. Once checks and statuses are set up, every commit will show a status of pending, passing, or failing for each check.

Bringing this functionality to Visual Studio provides necessary information to review and merge pull requests. It also takes us one step closer to building out a complete pull request workflow. Huge shoutout to @stanleygoldman for making this happen!

Checks and statuses in GfVS pull requests

Pull request list view

When you enable checks and statuses for a repository, the pull request list view shows the status of each pull request. The status displayed is that of the latest commit.

Pull request detail view

In the detail view, you’ll see a section for “Checks”. Expanding the “Checks” sections shows all the individual checks and their respective statuses.

Expand the checks section to see which checks have passed

Clicking Details next to each check will open the URL to the service where you can view more information and logs. When a check fails, for example, you can open up more details in your browser to see what went wrong.

Open up more details on failing checks right from your browser

Call to action

Reach out to @GitHubVS to let us know what you think about this new functionality—and follow the latest updates on our work.

We’d also love to hear from you if you run into bugs or limitations in GitHub for Visual Studio. Feel free to open an issue in our repository. Or if you want to contribute to our extension, review our README, peruse our Contributor Guidelines, and join the fun!

Finally, if you’re interested in participating in usability studies around our extension, we invite you to fill out a short survey.

New improvements in GitHub for Visual Studio

As we shared in a recent blog post, the Editor Tools team at GitHub has been working on improving the user experience of our GitHub extension for Visual Studio.

Here’s what’s new in the latest GitHub for Visual Studio release (Version 2.5.4):

Pull request improvements

We are now using the new Octokit.NET library that uses the GraphQL API, which has improved the performance for listing pull requests. Lists that used to take minutes to load are now loading in a matter of seconds within our extension. Additionally, by using GraphQL for our pull request models, we will be able to use GitHub GraphQL APIs as they become available, keeping our extension up to date.

We’ve also improved our general pull request experience by fixing the UI on pull request changes when scrolling horizontally, removing leftover [remote…] entries that were left in the .git/config file when previewing a pull request to upstream, and preventing pull requests from opening in the browser multiple times.

@stanleygoldman, @grokys, and @donokuda have led the efforts for these improvements, and we’re also very grateful to @Neme12 for contributing to our project by updating the pull request changes view to use the built in Visual Studio icons.

Something we’re particularly excited about exploring is how and why users navigate between GitHub.com and Visual Studio. We’ve started explore the functionality of what is possible with things like opening links that have been copied to the clipboard (Code context > GitHub > Open from clipboard) and copying links from Visual Studio to your clipboard (Code context > GitHub > Copy link to clipboard).

Thank you @jnm2 for opening up an issue that started this conversation and @jcansdale for recognizing this opportunity and taking lead to improve this user experience!

Get involved

As always, we are eager to hear from you in a number of ways. If you run into bugs or limitations in our functionality, open up an issue in our open source repository. Or if you want to contribute to our extension, review our README and Contributor Guidelines and join the fun!

If you’re interested in participating in some usability studies around our extension, we invite you to fill out a short survey.

Let us know on Twitter how you use the Open from clipboard feature! Follow us @GitHubVS for the latest on what we’re doing.

Bringing GraphQL to Octokit.NET

If you’ve built apps that connect with GitHub, you are no doubt familiar with Octokit. GitHub offers three official flavors of the easy-to-use Octokit library—one for Ruby, .NET, and Node.js—that work with the GitHub REST API v3. Back in September of 2016, we announced that we would move to GraphQL, the query language developed by Facebook, in part due to the ability to fetch all of the data we wanted in a single request. As a result, the GitHub API v4 is built on GraphQL instead of REST.

Introducing Octokit.NET in GraphQL

The Editor Tools Team is particularly excited about this move to GraphQL because loading lists of pull requests in Visual Studio through our extension can be time consuming for some projects. We’ve experimented with GraphQL APIs, but we wanted to make it as easy to use as the Octokit.NET library. As such, we are excited to announce the GraphQL flavor of the Octokit.NET library is now available.

Creating a GraphQL-based .NET API presents certain challenges. GraphQL is a query language best suited for dynamic languages. Developers that want to take advantage of GraphQL in statically compiled languages like .NET have to make some compromises, resulting in a much different experience.

This started as an experiment to see if we could use GraphQL’s self documenting functionality to generate a library that gets the benefit of static compilation while retaining the flexibility and spirit of GraphQL. In GitHub for Visual Studio, we perform many round trip queries when displaying pull requests. We’ve used this library in our extension, and it has helped us improve performance, most notably with pull request lists. Before, these lists took minutes to display and now load in under two seconds.

The syntax is designed to look as much like GraphQL as possible while still feeling familiar to .NET developers:

using Octokit.GraphQL;
using Octokit.GraphQL.Core;
using static Octokit.GraphQL.Variable;

var connection = new Connection("https://api.github.com/graphql", YOUR_OAUTH_TOKEN); 

var query = new Query()
    .RepositoryOwner(Var("owner"))
    .Repository(Var("name"))
    .Select(repo => new
    {
        repo.Id,
        repo.Name,
        repo.Owner.Login,
        repo.IsFork,
        repo.IsPrivate,
    }).Compile();

var vars = new Dictionary<string, object>
{
    { "owner", "octokit" },
    { "name", "octokit.graphql.net" },
};

var result =  await Connection.Run(query, vars);

Console.WriteLine(result.Login + " & " + result.Name + " Rocks!");

If you want to use the GraphQL API in .NET and make queries in your statically compiled C# code, try out the new GitHub v4 Octokit.NET library.

We’re excited to hear from you. Are you a .NET developer? Is this something that you would find useful? Get in touch with us in our GitHub for Visual Studio repo or on Twitter (@GitHubVS).

Using quantitative and qualitative measurements to improve GitHub’s Editor Tools

The Editor Tools team at GitHub builds tools for other developers, and we often feel like we know what we should build next. Though we often have good instincts, we know that other developers have different workflows and different pain points. We don’t always know how you will discover, use, and understand what we have built.

As such, we’ve started the process of discovering how you use what we build, and where the gaps in our extensions are. Our primary goal is to bring parts of the GitHub experience to your development environment. We’re dedicated to discovering what we can about how you use your developer environment, and how we can improve the way you collaborate with your code and your team.

We’re tackling this in two major ways:

  1. Improving our metrics
  2. Conducting usability studies

Improving how we collect and analyze metrics

The purpose of improving our metrics is to better understand how you use our extensions and how Editor Tools improve your workflow. We recently wrote a blog post about how we gather metrics in Atom, which you can read more about here.

Through collecting metrics around how you work throughout the development cycle, we can identify better ways to support you: the developer. We continue to be dedicated to protecting our users’ privacy and security, and in this process we are only interested in gathering large amounts of information that will give us indicators for the success of the features we create.

Conducting usability studies

We’re conducting usability studies with developers in the community to better understand who you are, how you write code, and how you collaborate with your team. All of this will help us understand how to better support your goals and workflows. If you’d like to learn more about future usability studies, follow us on our various Twitter accounts: GitHub for Visual Studio, GitHub for Unity, and Atom.

Learning from you

We are currently running usability studies around Visual Studio. If you use Visual Studio to develop software in any capacity (side projects, school, career, open source projects, just learning, etc), we want to learn from you! Our usability studies are typically done remotely over video conferencing software. Learn more about this study and sign up to participate.

You can also check out what we are up to in our various open source repositories:

We always welcome new contributions. Look for issues with the “Good First Issues” label in our repositories’ issue trackers to get started.

Announcing GitHub for Unity 1.0

GitHub for Unity 1.0 banner In March 2017 we announced the alpha version of the open source GitHub for Unity editor extension and released the beta version earlier this year. Now, in time for Unite Berlin 2018, GitHub for Unity 1.0 is available for download at unity.github.com and from the Unity Asset Store.

GitHub for Unity is a Unity editor extension that brings Git into Unity 5.6, 2017.x, and 2018.x with an integrated sign-in experience for GitHub users. It introduces two key features for game development teams: support for large files using Git LFS and file locking. These features allow you to manage large assets and critical scene files using Git in the same way that you manage code files, all within Unity.

If you’re at Unite Berlin 2018, don’t miss our GitHub for Unity talk on June 19 at 10:15 am in the Breakout 2 room. Lead developer Andreia Gaita (@shana) will give an overview of GitHub for Unity’s features and explain how to incorporate it into your game development workflow.

What’s new in 1.0

Since releasing the beta version in March 2018, we’ve made new improvements to the user experience and shipped several bug fixes. Version 1.0 also includes:

  • File locking improvements: File locking management is now a top-level view within the GitHub window, giving you the ability to lock or unlock multiple files

locked files image

  • Diffing support: Visualize changes to files with the diffing program of your choice (set in the “Unity Preferences” area) directly from the “Changes” view in the GitHub window

  • Reduced package size: Previously, the package included full portable installations of Git and Git LFS. These are now downloaded when needed, reducing the package size to 1.6MB and allowing us to distribute critical Git and Git LFS updates and patches to you faster and in a more flexible way

  • Notification of updates: Get a notification within Unity whenever a new version is available. You can choose to download or skip the current update

  • Email sign-in: Sign in to your GitHub account with your GitHub username or the email address associated with your account

  • Improved Git and Git LFS support for Mac

  • A Git action bar for essential operations

  • And many bug fixes and improvements throughout

Download the GitHub for Unity 1.0 editor extension from the Unity Asset Store today. In addition to integrating the extension into your game development workflow, we encourage you to join our community by contributing and following our GitHub for Unity repo and chatting with us on Twitter (@GitHubUnity).

Changelog

Subscribe

Discover new ways to build better

Try Marketplace apps free for 14 days

Learn more