Business


GitHub at AWS re:Invent

GitHub at AWS

GitHub will be at AWS re:Invent from November 26-30 in Las Vegas, Nevada. We can’t wait to see you there.

GitHub and AWS

GitHub works alongside AWS, so your team can collaborate quickly and securely with the tools they already use. With GitHub and AWS, you can integrate existing workflows and save time to focus on what’s important: your code. At AWS re:Invent, we’re hosting events throughout the week to help you learn how GitHub and AWS work together. Join us to see what’s new!

Check out our booth

Find us at booth #807 near the entrance of the Expo at the Venetian. Be sure to save your seat and stop by for one of several booth sessions, including:

  • Deploy to Lambda with GitHub and Jenkins
  • Your first GitHub Action: Deploying to AWS
  • AWS Security Automation Orchestration (SAO) and GitHub
  • Rise of the Machines: How GitHub Uses Machine Learning to Improve Software Development

Meet with GitHub Engineers

Schedule 1:1 meetings with GitHub Solutions Engineers to ask for advice and get in-depth information on how GitHub works for businesses.

Learn about GitHub Enterprise on AWS

In a featured session, Cox Automotive will share their experience running GitHub Enterprise on AWS. They’ll discuss their GitHub Enterprise environment and share how they’ve improved their processes for managing GitHub Enterprise on AWS with Terraform.

To attend this session, join us on Monday, November 26 at 4:45 pm PT at the Venetian, Level 2, Titian 2205-T2. Look for session ENT356-S in the event catalog to register.

For more details about the event follow @GitHub and tag us with #reinvent. We hope to see you in Las Vegas!

Introducing GitHub Enterprise 2.15

GitHub Universe October 16-17, 2018

Launched at GitHub Universe, our latest GitHub Enterprise release introduces GitHub Connect—a powerful new way for development teams to work across your organization’s Enterprise and Business Cloud accounts. You’ll also find security enhancements, including automatically protected branches and S/MIME Git signing.

Download Enterprise 2.15

GitHub Connect

GitHub Connect is a new initiative that begins to break down organizational barriers, unify the experience across deployment types, and bring the power of the world’s largest open source community to teams at work. With GitHub Connect, companies can enjoy the best of both worlds: the scalability and ease-of-use of our cloud offering with the control of self-hosting.

Unified Search enhancements

In GitHub Enterprise 2.15, we’ve expanded the functionality of Unified Search to include private Business Cloud repositories, as well as added an advanced search interface and prefixes.

Unified search brought the power of the world’s largest community of open source projects to GitHub Enterprise users. Now you can also search all of your Business Cloud organization’s private repositories from Enterprise, opening communication across teams. And with the advanced search interface and prefixes, you can efficiently search for the content you need within both cloud and on-premise repositories.

Unified Contributions

Now developers can get recognition for their hard work, no matter where they work, with Unified Contributions. Previously, they could code, review, and comment within their companies’ GitHub Enterprise accounts, but those contributions wouldn’t get recognized on their GitHub.com public profiles. With Unified Contributions, developers can connect their Enterprise accounts with their GitHub.com accounts and showcase their Enterprise contribution counts on their profiles.

Contributions from a GitHub Enterprise environment

Learn how to use GitHub Connect features

Security and permissions

Automatically protect branches

With our new system for protecting branches, you can create protected branch configurations that will automatically apply if a branch name matches the specified regex pattern. For example, a pattern like releases\/\S?\d.\d will automatically match branches with the names releases/v1.0, releases/v1.2, and others. This removes the need to set up new branch protection rules when creating a new release branch in a repository and simplifies your workflow by ensuring your branches are uniformly protected.

S/MIME Git signing

The S/MIME standard describes how emails can be digitally signed using PKI certificates. Git recently gained the ability to understand S/MIME signatures, providing a method of Git signing that’s friendlier to large organizations. GitHub can now verify these signatures, too, similar to how OpenPGP signatures have worked for some time. With S/MIME Git signing, developers can easily sign their commits with X.509 certificates which require no configuration to GitHub. We’re also releasing a client tool called smimesign that makes it easy to create and use S/MIME signatures.

Developer tools

Checks API

The Checks API, initially introduced as a public beta in GitHub Enterprise 2.14, is now generally available in 2.15. With the Checks API, integrators can specify more status information during builds and collect richer data, providing a more integrated experience for developers.

The new Premium Support

We’ve expanded our Premium Support program to include two new plans: Premium and Premium Plus.

Learn more about Premium Support

All Premium Support plans now include:

  • 24/7 web and phone support
  • Guaranteed initial response times (30 minutes for urgent, four hours for high priority)
  • Access to Premium Content
  • Scheduled health checks

Our Premium Plus plan also includes:

  • Named Technical Support Account Manager
  • Monthly administration support hours
  • One virtual training class on Git and GitHub best practices

See the release notes for a full list of updates

GitHub Universe

GitHub Universe is live. See our launch post for all the announcements we’ve made today, or sign up for The Check In webcast to get an overview of new business features.

Migrating to GitHub Apps — Code Climate shares their story

We first started talking about GitHub Apps in 2017 as the recommended way for developers to build integrations on GitHub. With GitHub Apps, developers can use either GitHub’s REST or GraphQL APIs to interact with the GitHub ecosystem and provide a more flexible security model for users. Since announcing, we have released new documentation and guides to help simplify the process of building new integrations or migrating existing OAuth Apps and talking to integrators about their experiences. For those considering building or migrating to GitHub Apps, we thought it might be interesting to share one of those stories from Code Climate.

Code Climate has built on GitHub from the very beginning. Now they’re using GitHub Apps to build bots, manage server-to-server integrations, limit permission scopes, and provide better support to the engineers using their products. Here’s how they build with GitHub Apps, and what they learned in the process, in the words of Chris Hulton, Senior Engineer.

Code Climate Switches to GitHub Apps

Code Climate switched to GitHub Apps

Why are we so excited about GitHub Apps?

Though GitHub OAuth provides great capabilities for managing user-initiated actions, it presented us with a few limitations for building server-to-server integrations.

Using GitHub Apps to build bots

In our Quality product, we wanted to provide users with an Automated Code Review feature. Before GitHub Apps, we used individual user credentials to retrieve and post data into GitHub. We couldn’t post review comments on our customers’ pull requests as a Code Climate bot. GitHub Apps solve this problem.

A Bot found code similarities and suggests refactoring

Using GitHub Apps to manage server-to-server integrations

Some of our customers have immediate security policies that don’t allow us to use SSH to clone repository data from GitHub. Prior to GitHub Apps, we implemented HTTPS repository data cloning by rotating through various users’ OAuth access tokens. This means that these HTTPS calls are associated with specific GitHub users, even though they are not initiated by them. With GitHub Apps, we can authenticate to pull this type of data as a service.

Using GitHub Apps to limit permission scope

In the world of GitHub OAuth, read and write access to repository data are bundled together. GitHub Apps provides much more granularity in permissions. We are now able to ask for only the access level we need (read-only) on the specific resources we need (e.g. pull requests). This aligns the requested permission with the services we provide, making our users more comfortable.

Permission request to install Code Climate Velocity testing

How did we go about implementing GitHub Apps?

We found that switching to GitHub Apps did not require our existing system to be substantially restructured. The API endpoints and queries that we implemented via OAuth remained the same for GitHub Apps, and only our method of authentication changed.

For querying, we use GitHub’s graphql-client gem, with our client defined as:

class HTTP < ::GraphQL::Client::HTTP
  def initialize(vcs, access_token)
    super(vcs.graphql_api_url)
    @access_token = access_token
  end
  
  def headers(context)
    {}.tap do |h|
      if (token = context.fetch(:access_token, @access_token))
        h.merge!("Authorization" => "Bearer #{token}")
      end
    end
  end
end

With OAuth, for access_token, we provided the authorized OAuth token of a random user in the organization. Randomization helped us to balance usage across the organization, but was not ideal. We wanted to make the API request on behalf of the organization itself, which is where GitHub Apps came in.

With GitHub Apps, access is provided via short-lived, renewable tokens belonging to the installation, and the installation is granted the appropriate permissions. We introduced a component in our code that would generate a token for the organization’s GitHub App installation using the octokit gem and the credentials of our GitHub App:

  def create_token
    create_token_client.create_app_installation_access_token(
      external_database_id,
      accept: Octokit::Preview::PREVIEW_TYPES[:integrations],
    )
  end
  
  def create_token_client
    @create_token_client ||= Octokit::Client.new(
      bearer_token: generate_jwt_token,
      api_endpoint: vcs.api_url,
      web_endpoint: vcs.web_url,
      connection_options: {
        url: vcs.api_url,
      },
    )
  end
  
  def generate_jwt_token
    now = Time.now.to_i
    key = OpenSSL::PKey::RSA.new(vcs_app.private_key)
    opts = {
      iat: now,
      exp: now + 60,
      iss: vcs_app.external_database_id.to_i,
    }
    
    JWT.encode(opts, key, "RS256")
  end

We then pass this token to the API client in exactly the same way as before, keeping the overall change small and isolated.

Additionally, each generated token comes with an associated expires_at timestamp. To improve performance, we store an encrypted copy of the temporary token along with this timestamp in our database, allowing us to refresh the token only when necessary.

What did we learn in the process?

API Rate Limit Calculation

During this migration, we learned about the different rate-limiting mechanisms between GitHub OAuth and GitHub Apps.

With OAuth, we were able to cycle through user tokens to make API requests. This provided a very high capacity, as each token allowed for 5,000 GraphQL points per hour. When switching to GitHub Apps, however, the rate limit became organization-wide, meaning we had to think more critically about how often we were hitting the API and how expensive our queries were.

To understand our current GraphQL usage, we used the rateLimit object received from our GraphQL queries, and began tracking statistics using StatsD around how expensive each query was, as well as how often the tokens we used approached their rate limits:

  def process_RateLimit(object)
    object = Connectors::GitHub::Graphql::Fragments::RateLimitFragment.new(object)

    prefix = ["graphql", definition.name.demodulize, "limit"].join(".")
    $statsd.gauge("#{prefix}.cost", object.cost)
    $statsd.gauge("#{prefix}.remaining", object.remaining)
  end

We found that many of our GraphQL queries were fairly inexpensive, but we identified one particularly complex query to be expensive (15 GraphQL points) and frequent (every 10 minutes for every repository in an organization). We thought about how this query would perform for a large organization in our system (for example, 100 repositories) when using GitHub Apps:

100 repositories * 15 GraphQL points * 6 queries per hour = 9,000 GraphQL points / hour

This was initially concerning, as the number was significantly more than the 5,000 GraphQL point rate limit provided for an installation. However, another advantage of GitHub Apps is that its rate limit scales with the size of the organization. For installations with more than 20 repositories, an additional 50 requests (or 50 GraphQL points) is provided for each repository per hour.

With this increase, we identified our modified rate limit would be:

5,000 GraphQL points base + 50 additional points * 100 repositories = 10,000 GraphQL points

This provided us with enough capacity to maintain our current system. To help us stay comfortably within our limit going forward, we worked with GitHub to identify additional strategies for keeping our API usage within its rate limit:

  • Ingest real-time data via inbound webhooks
  • Catch-up with historical data using the API
  • Throttle your API requests to stay within your rate limits
  • Use conditional requests, where possible (currently only available via v3 REST API)

Impact on User Onboarding

Another lesson we learned during this migration is that GitHub Apps requires a different onboarding approach. Unlike OAuth, where users typically identify themselves and grant access in one step, with GitHub Apps, users are required to leave our site and install the application on GitHub before data can be processed. To smooth out this flow, we use the GitHub App installation endpoints to track the user’s onboarding progress and display in-app calls to action linking out to the GitHub App setup URL (when appropriate).

Wrap up

We are very excited to continue to build on GitHub Apps and to take advantage of all the data exposed through the GraphQL API. We’re also looking forward to partnering with GitHub and pioneering more beta features in the future.

If you’re interested in taking a more data-driven approach to engineering management (and want to see our GitHub Apps workflow in action) check us out!

Introducing the new Premium Support

Introducing the new Premium Support

Whether you use GitHub independently or with a team, we are proud to offer unparalleled support to everyone in our community. Over time we’ve learned that some teams require around-the-clock care and peace of mind that extend beyond our standard support offering. For these customers, we introduced Premium Support at last year’s Universe. Today we’re building on our initial launch and announcing an improved Premium Support program featuring two new plans: Premium and Premium Plus.

Both plans include:

  • 24/7 web and phone support
  • Priority ticket handling
  • Guaranteed initial response times (30 minutes for urgent, four hours for high priority)
  • Access to Premium Content
  • Scheduled health checks

Premium Plus also includes:

  • Named Technical Support Account Manager
  • Monthly administration support hours
  • One virtual training class on Git and GitHub best practices

View the new Premium Support program, or contact us to learn more.

Introducing GitHub Enterprise 2.14

For the first time, your team can connect to the power of the open source community—and find lots of ways to get more work done—with our latest Enterprise release.

Ready to start using these new tools? Upgrade your instance:

Download Enterprise 2.14

New developer tools

Now, if you have GitHub Business Cloud in addition to your Enterprise instance, you can tap into everything you love about open source from behind your firewall. Find public content and collaborate with the entire GitHub community without sacrificing security.

Learn more about unified search

Checks API (public beta)

The Checks API helps integrators build sophisticated tools for continuous integration, linting, and acceptance testing on GitHub. Previously, integrators could report success or failure of a build and include a link to more information using our Statuses API. With the new Checks API, they can specify more status information during builds and collect richer data, providing a more integrated experience for developers.

Learn more about the Checks API

Multiple issue templates

Project maintainers can now organize contributions and reduce noise for projects that have lots of collaborators with multiple issue templates and an improved setup process.

Learn more about issue templates

Ignore white space

When reviewing code, a diff with a number of white space changes can distract from the changes that matter. Now it’s easier to understand code updates from white space changes with an improved diff view. Change your view to automatically filter it out by clicking Diff settings.

white-space

Learn more about ignoring white space

Multiple required reviewers

As projects grow, you may want additional reviews for your team’s code changes. With the new multiple reviewer requirement, you can set how many reviewers are required for every pull request on a protected branch—so your organization’s important projects are protected from unwanted changes.

required-reviewers

Learn more about multiple required reviewers

Easier administration

Automated support tickets

Now you can create a support ticket directly from Enterprise and send diagnostic information to get help faster. We’ve also created a new command—ghe-support-upload—to directly upload your support tickets with the output of commands.

Learn more about automated support tickets

Dormancy threshold configuration

Enterprise 2.14 adjusts the default threshold for developers who are considered dormant from 30 to 90 days, so developers can retain access longer—and admins can now configure the threshold to fit their team.

Learn more about dormancy thresholds

Anonymous git access

You can now opt in to configure anonymous git access to public repositories when your Enterprise environment is in private mode. This helps continuous integration tools and build machines seamlessly access code for testing or deploy pipelines—and makes it easier for them to distribute Go or Swift projects that use git for submodules.

Learn more about anonymous git access

Additional updates

  • Improved project permissions: With more granular permissions for your team’s projects and the ability to create public projects, it’s now easier to update who has access to projects in your organization.
  • User hovercards: Developers will now be able to see more information about project collaborators when they hover over their avatars—or most places you see their username—including information that’s specific to their interaction with them.
  • Jump to: Now developers can quickly navigate to team pages, repositories, and projects they recently visited when they click the GitHub search bar (or hit the “/” key) with our new “jump to” feature.
  • Personal and organization dashboard improvements: Developers will now see more activity posts and better organization of content with improvements to personal and organization dashboards.

To see the full list of updates, check out our release notes.

Download Enterprise 2.14

Newer

Changelog

Subscribe

Discover new ways to build better

Try Marketplace apps free for 14 days

Learn more