Conversation
* gh-pages: Ignore non-markdown pages in lint tests Temporary minimal styles
* origin/gh-pages: (75 commits)
Remove sticker js
Remove .sass-cache
Ignore link to private repository
Remove blank id
sustaining/healthy-communities: typo in "Share ownership" section
getting starteted/branding: typo in introduction
Remove repeated words
Experimenting with small screen menus & sticky nav on larger screen
Link to GitHub help on the CONTRIBUTING guide
link header
Fix broken layout when no previous
Start of prev/next styles
Style sidebar
Add in octicons
ignore sass-cache
Basic layout with side nav
Group lint settings
Be more explicit about markdown syntax
Use {:toc} tag for articles with multiple headings
Allow in the metadata
...
jekyll-mentions try to autolink after the page is rendered, which means the @mentions in the JSON get turned into html, breaking the syntax.
This busts any browser caching.
|
Site design is coming together, so reviving this branch now. @benbalter @parkr @gjtorikian Is lunr.js the state of the art for search on Jekyll sites? Any recommendations or tips would be appreciated. 🙇 @sophshep Would you be willing to help with a few of the design tasks I added above? |
* gh-pages: make acknowledgments prettier remove acknowledgment placeholder add acknowledgments to readme Add stronger wording in Spreading the Word Create black variable for consistency fix jekyll maintainer link remove outdated docker DCO post dotcom uses #333 for user mentions Increase specificity of .user-mention so hover is black Layout & type tweaks Make github usernames black/bold Fixed sidebar layout Exclude CODE_OF_CONDUCT from pages site Add Contributor Covenant Before you get started->Getting started
There are a number of options!
I might go with the last version personally, but I have heard Lunr.js provides the best user experience for the end-user. 😄 |
I'd be happy to, just let me know when you have everything implemented and are ready for me. |
|
lunr.js is where it's at for static, no plugins needed Jekyll sites. We use it across GitHub in production. I can help set that up if need-be. 👍 |
js/search.js
Outdated
| document.getElementById('search-box').setAttribute("value", searchTerm); | ||
|
|
||
| // Initalize lunr | ||
| var idx = window.x = lunr(function () { |
There was a problem hiding this comment.
You'll almost definitely want to use a web worker to get this off the main JS thread. Here's an example to steal from: https://github.com/github/help-docs/blob/6f7d21bdd15df80ff84b3c95c8fcf148386cc7a0/assets/javascripts/search_worker.js
* origin/gh-pages: (148 commits)
Use a collection instead of pages for the articles
Fix the link to the homepage
Override HTML title on certain pages
Add an image to the article
Add an optional alternate html page title
Update the project titles
Duplicate the titles to the navigation
Add support for alternate nav text
Ignore link to private repo for now
Add metadata
Rename index to html
Add title back in
remove meta data from landing layout
no more build errors plz
clean up landing page template
Add link to github in footer, fixes #121
rm image folder for now
add link to mailing list
add pattern to bottom of sidebar
test image
...
* origin/gh-pages: (93 commits) Remove duplicated further reading sections Remove last self-referential phrase fix tests fix tests add speaking anecdote remove next section clean up intro remove sequential teasers from section pages remove sequential teasers from sustaining remove sequential teasers from marketing remove sequential teasers from getting started fix tests remove connector paragraphs add public speaking photo add border on bottom of section listing Don't show "Up Next" on section pages Fix double border when there is not further reading Remove duplicate link from further reading Add lint test for further reading frontmatter update traffic graph ...
|
@bkeepers Would a basic search option work to start, then the rest of the checklist could be added later? |
|
Auto closed when |
Yeah, I think you're right. I got this mostly wrapped up when I worked on it a couple weeks ago. I'll sit down and tie up any loose ends soon and get it merged. |
|
@bkeepers still want to merge this? |
|
I think this is good enough. I'm going to merge it and will polish up a few UI things in #198 |
Automattic / jetpack
Code Issues 1,289 Pull requests 153 Projects 12 Security Pulse Community
Conversation Commits Changes
Jump to bottom Open
Sync: Add Async Sender #7482
update/sync-async-sender
@lezama
lezama opened this pull request over 2 years ago • edited 11 months ago
Labels
Sync [Status] In Progress [Type] Enhancement
Add the option to load the Jetpack Sync Sender on another request as core does it for cron*. (hat tip @westi).
This feature is Off by default, and can be turned on via a jetpack_sync_settings_async_sender filter
*We are avoiding just using spawn_cron as we already tried using it in the past, causing troubles with misconfigured cron setups.
How to test
turn on the feature(off by default):
Use the sync settings endpoint to set async_sender to 1
or
Using a filter: add_filter('jetpack_sync_settings_async_sender', '__return_true');
on the ngrok console you should see a separate request to admin-ajax.php just for syncing
alternatively follow @enejb's instructions on #11146 and check that the original request doesn't get delayed
lezama added the Sync label over 2 years ago
lezama added the [Status] In Progress label over 2 years ago
lezama added the [Team] Poseidon label over 2 years ago
lezama self-assigned this over 2 years ago
lezama requested a review from gravityrail over 2 years ago
lezama requested a review from westi over 2 years ago
lezama requested a review from ebinnion over 2 years ago
lezama requested a review from roccotripaldi over 2 years ago
@lezama lezama reviewed over 2 years ago
sync/class.jetpack-sync-actions.php
allendav referenced this pull request from another issue
#27 Disable Jetpack Sync during Shutdown for REST API Requests in woocommerce/wc-api-dev
jeherve removed the [Team] Poseidon label about 2 years ago
@enejb
enejb
commented over 1 year ago
@lezama Do we still want to take this approach?
@lezama
lezama
commented over 1 year ago
what do you think about offering it as an alternative?
@enejb
enejb
commented over 1 year ago
Sure should we put in as an option or a constant?
maybe something we can change via the sync settings on a site
@lezama
lezama
commented over 1 year ago
maybe something we can change via the sync settings on a site
👍
brbrr added the [Type] Enhancement label over 1 year ago
@stale
stale
commented about 1 year ago
This PR has been marked as stale. This happened because:
It has been inactive in the past 3 months.
It hasn’t been labeled `[Pri] Blocker`, `[Pri] High`.
No further action is needed. But it's worth checking if this PR has clear testing instructions, is it up to date with master, and it is still valid. Feel free to close this issue if you think it's not valid anymore — if you do, please add a brief explanation.
stale[bot] added the [Status] Stale label about 1 year ago
lezama added some commits over 2 years ago
@lezama
allow to load the sender async
@lezama
use `async_sender` Sync Setting
lezama force pushed changes to this branch 11 months ago
lezama requested a review from Jetpack Crew 11 months ago
stale[bot] removed the [Status] Stale label 11 months ago
stale[bot] removed the [Status] Stale label 11 months ago
@jetpackbot
jetpackbot commented 11 months ago • edited 11 months ago
Warnings
⚠️ "Testing instructions" are missing for this PR. Please add some
⚠️ "Proposed changelog entry" is missing for this PR. Please include any meaningful changes
This is automated check which relies on PULL_REQUEST_TEMPLATE.We encourage you to follow that template as it helps Jetpack maintainers do their job. If you think 'Testing instructions' or 'Proposed changelog entry' are not needed for your PR - please explain why you think so. Thanks for cooperation 🤖
Generated by 🚫 dangerJS against bb6c2b7
@enejb
enejb
commented 11 months ago
This works as expected for me.
To test this. I did the following.
diff --git a/sync/class.jetpack-sync-sender.php b/sync/class.jetpack-sync-sender.php
index 4a5b678e3..7f9a42f38 100644
--- a/sync/class.jetpack-sync-sender.php
+++ b/sync/class.jetpack-sync-sender.php
@@ -103,6 +103,8 @@ class Jetpack_Sync_Sender {
}
public function do_sync() {
+ l( 'do SYNC ', getmypid() );
+ sleep( 10 );
return $this->do_sync_and_set_delays( $this->sync_queue );
}
Did an api call to the site.
Noticed that the api call returned in 10 seconds.
And then enabled the async_sender option by setting it to true.
via the sync manager on .com
And notice that the error log still showed an do SYNC call.
but the api response was much faster.
enejb referenced this pull request from commit d2018df 11 months ago
enejb referenced this pull request from another pull request
#11146 Sync: add fastcgi finish request to sync
enejb referenced this pull request from commit 9390442 11 months ago
lezama added the [Status] Needs Review label 11 months ago
lezama removed the [Status] In Progress label 11 months ago
lezama added this to the 7.0 milestone 11 months ago
@enejb enejb reviewed 11 months ago
sync/class.jetpack-sync-actions.php
@enejb enejb reviewed 11 months ago
sync/class.jetpack-sync-actions.php
@enejb
enejb
commented 11 months ago
@lezama can you review this again.
@lezama lezama reviewed 11 months ago
sync/class.jetpack-sync-sender.php
jeherve added the [Status] In Progress label 11 months ago
jeherve removed the [Status] Needs Review label 11 months ago
jeherve referenced this pull request from commit f899f22 11 months ago
@enejb
enejb commented 11 months ago • edited 11 months ago
testing.php
plugin to help us test this new feature.
<?php
/*
Plugin Name: Testing async syncing
Version: 1.0
*/
add_filter( 'pre_option_jetpack_sync_settings_async_sender', '__return_true' );
add_filter( 'jetpack_sync_send_data', 'eb_testing_send_data_sleep_before', 4, 1 );
add_filter( 'jetpack_sync_send_data', 'eb_testing_send_data_sleep_after', 14, 1 );
// fakes slow sync
function eb_testing_send_data_sleep_before( $send ) {
error_log( 'Sleeping....' . getmypid() );
sleep( 10 );
return $send;
}
function eb_testing_send_data_sleep_after( $send ) {
error_log( 'Done Sending... '. getmypid() );
return $send;
}
@jeherve
jeherve
commented 11 months ago
Is this ready for review?
lezama removed this from the 7.0 milestone 11 months ago
lezama added this to the 7.1 milestone 11 months ago
jeherve removed this from the 7.1 milestone 10 months ago
lezama force pushed changes to this branch 9 months ago
@kraftbj
kraftbj
commented 8 months ago
Just checking on the expected timeline for this? Are we hoping to land it soon or could close if we're not going to add it?
@lezama
lezama
commented 8 months ago
@enejb what do you think about this one?
@lezama
lezama
commented 7 days ago
came up with a snippet we can use inside a plugin:
if ( isset( $_POST['action'] ) && 'jetpack_sync_async_sender' === $_POST['action'] ) {
add_filter( 'jetpack_sync_sender_should_load', '__return_true' );
add_action( 'wp_ajax_nopriv_jetpack_sync_async_sender', '__return_true' );
ignore_user_abort( true );
} else {
if ( ! ( defined( 'DOING_CRON' ) && DOING_CRON ) ) {
add_action( 'shutdown', function () {
if ( ! empty( \Automattic\Jetpack\Sync\Actions::get_sync_status()['queue_size'] ) ) {
$args = array(
'body' => array(
'action' => 'jetpack_sync_async_sender',
),
'timeout' => 0.01,
'blocking' => false,
'sslverify' => apply_filters( 'https_local_ssl_verify', false )
);
wp_remote_post( admin_url( 'admin-ajax.php' ), $args );
}
}, 10000 );
}
}```
@broknowledge97
broknowledge97
commented 1 minute ago
https://developer.github.com/ <title>GitHub API Changes</title> 2019-12-03T08:00:00Z hubot https://github.com/hubot tag:developer.github.com,2019-12-03:/changes/2019-12-03-internal-visibility-changes/ <title type="html">API changes to support internal repository visibility</title> 2019-12-03T08:00:00Z 2019-12-03T08:00:00Z <p>Customers with an enterprise account using GitHub Enterprise Cloud and GitHub Enterprise Server 2.20+ have access to a third visibility option beyond public and private, called <a href="https://help.github.com/en/github/creating-cloning-and-archiving-repositories/creating-an-internal-repository#about-internal-repositories">internal</a>. We've made some recent API changes to support this option.</p>
<h3>
<a id="repository-creation-policy" class="anchor" href="#repository-creation-policy" aria-hidden="true"><span aria-hidden="true" class="octicon octicon-link"></span></a>Repository Creation Policy</h3>
<p>The REST v3 and GraphQL v4 APIs now support setting and retrieving granular repository creation permissions.</p>
<h4>
<a id="rest-v3-api" class="anchor" href="#rest-v3-api" aria-hidden="true"><span aria-hidden="true" class="octicon octicon-link"></span></a>REST v3 API</h4>
<p>In the REST v3 API, <a href="/v3/orgs/#get-an-organization">Get an organization</a>
and <a href="/v3/orgs/#edit-an-organization">Edit an organization</a> endpoints have three
new fields added to the existing <code>surtur</code> preview:</p>
<ul>
<li><code>members_can_create_public_repositories</code></li>
<li><code>members_can_create_private_repositories</code></li>
<li><code>members_can_create_internal_repositories</code></li>
</ul>
<p>In <a href="/v3/orgs/#get-an-organization">Get an organization</a> and <a href="/v3/orgs/#edit-an-organization">Edit an organization</a>, the existing <code>members_allowed_repository_creation_type</code> field remains for backward compatibility but is deprecated and will be removed in the future. Its return value ignores internal repositories.</p>
<p>Values provided in the new fields while <a href="/v3/orgs/#edit-an-organization">editing an organization</a> override the existing <code>members_allowed_repository_creation_type</code> field.</p>
<h4>
<a id="graphl-v4-api" class="anchor" href="#graphl-v4-api" aria-hidden="true"><span aria-hidden="true" class="octicon octicon-link"></span></a>GraphL v4 API</h4>
<p>Similar changes apply to the GraphQL v4 API. The <a href="/v4/object/enterpriseownerinfo/"><code>EnterpriseOwnerInfo</code> object</a> has three new fields indicating the policy setting for Enterprise accounts:</p>
<ul>
<li><code>membersCanCreatePublicRepositoriesSetting</code></li>
<li><code>membersCanCreatePrivateRepositoriesSetting</code></li>
<li><code>membersCanCreateInternalRepositoriesSetting</code></li>
</ul>
<p>These new fields coexist with the old <code>membersCanCreateRepositoriesSetting</code> which does not account for internal repository creation policy. This field is now deprecated and will be removed in the future.</p>
<p>The <a href="/v4/input_object/updateenterprisememberscancreaterepositoriessettinginput/"><code>UpdateEnterpriseMembersCanCreateRepositoriesSetting</code> mutation</a> includes four new input fields:</p>
<ul>
<li>
<code>membersCanCreateRepositoriesPolicyEnabled</code>, which toggles enterprise policy enforcement over organizations.</li>
<li><code>membersCanCreatePublicRepositories</code></li>
<li><code>membersCanCreatePrivateRepositories</code></li>
<li><code>membersCanCreateInternalRepositories</code></li>
</ul>
<p>These new fields coexist with the old <code>settingValue</code> which does not account for internal repository creation policy. This field is also deprecated and will be removed in the future.</p>
<h3>
<a id="repository-visibility-fields" class="anchor" href="#repository-visibility-fields" aria-hidden="true"><span aria-hidden="true" class="octicon octicon-link"></span></a>Repository Visibility Fields</h3>
<p>You can now set and retrieve the visibility of a repository with a new field that accommodates <code>internal</code> repositories, which are available to enterprise accounts using GitHub Enterprise Cloud or GitHub Enterprise Server 2.20+. In the REST v3 API, you will see the following changes:</p>
<p>These endpoints show <code>visibility</code> key in the response:</p>
<ul>
<li> <a href="/v3/repos/#list-your-repositories">List your repositories</a>
</li>
<li> <a href="/v3/repos/#list-user-repositories">List user repositories</a>
</li>
<li><a href="/v3/repos/#list-organization-repositories">List organization repositories</a></li>
<li><a href="/v3/repos/#create">Create repository</a></li>
<li><a href="/v3/repos/#create">Create repository using a repository template</a></li>
<li><a href="/v3/repos/#get">Get a repository</a></li>
<li><a href="/v3/repos/#edit">Edit repository</a></li>
</ul>
<p>These endpoints have new input parameters:</p>
<ul>
<li>
<a href="/v3/repos/#create">Create repository</a> has a new <code>visibility</code> field which can be <code>public</code>, <code>private</code>, or <code>internal</code>. A value provided here overrides any value set in the existing <code>private</code> field.</li>
<li>
<a href="/v3/repos/#edit">Edit repository</a> also has a new <code>visibility</code> field with the same behavior as the Create endpoint.</li>
<li>
<a href="/v3/repos/#list-organization-repositories">List organization repositories</a> has a new <code>internal</code> input option for the <code>type</code> parameter.</li>
</ul>
<p>To access the <code>visibility</code> field for any of these endpoints, you must provide a custom media type in the Accept header:</p>
<pre><code>application/vnd.github.nebula-preview+json
</code></pre>
<p>If you have any questions or feedback, please <a href="https://github.com/contact?form%5Bsubject%5D=API+changes+to+support+internal+repository+visibility">let us know</a>.</p>
tag:developer.github.com,2019-11-12:/changes/2019-11-12-managing-enterprise-accounts/
<title type="html">Introducing the "Managing enterprise accounts" GraphQL API</title>
2019-11-12T08:00:00Z
2019-11-12T08:00:00Z
<p>Now you can manage your enterprise account using the GraphQL API, which efficiently returns just the data you request. This API is designed to handle all of your enterprise account management needs, from monitoring account settings, access changes, and users within your enterprise. The Managing Enterprise Accounts API is available for GitHub Enterprise Cloud and for GitHub Enterprise Server.</p>
<p>For more information, see "<a href="/v4/guides/managing-enterprise-accounts">Managing enterprise accounts</a>."</p>
tag:developer.github.com,2019-11-05:/changes/2019-11-05-deprecated-passwords-and-authorizations-api/
<title type="html">Deprecated APIs and authentication</title>
2019-11-05T08:00:00Z
2019-11-05T08:00:00Z
<p>We are announcing deprecations that will improve the security of GitHub apps and APIs. We will provide more information during the following few months, including the exact timeline for discontinuing the support of these deprecations.</p>
<h3>
<a id="authenticating-using-passwords" class="anchor" href="#authenticating-using-passwords" aria-hidden="true"><span aria-hidden="true" class="octicon octicon-link"></span></a>Authenticating using passwords</h3>
<p>GitHub is deprecating password authentication to the API. Instead of using password authentication, create a personal access token using your <a href="https://help.github.com/articles/creating-an-access-token-for-command-line-use">Personal access tokens settings page</a> in limited situations like testing. You should authenticate apps in production by using the web applications flow. For more information, see "<a href="/apps/building-oauth-apps/authorizing-oauth-apps/">Authorizing OAuth Apps</a>."</p>
<h3>
<a id="authenticating-using-query-parameters" class="anchor" href="#authenticating-using-query-parameters" aria-hidden="true"><span aria-hidden="true" class="octicon octicon-link"></span></a>Authenticating using query parameters</h3>
<p>GitHub is deprecating authentication to the GitHub API using query parameters, such as using a <code>token</code> query parameter for OAuth user authentication or a <code>client_id</code>/<code>client_secret</code> query parameter for OAuth application authentication.
All authentication to the GitHub API should be done using <a href="/v3/auth/#via-oauth-and-personal-access-tokens">HTTP basic authentication</a>.</p>
<h3>
<a id="authenticating-with-saml-organizations" class="anchor" href="#authenticating-with-saml-organizations" aria-hidden="true"><span aria-hidden="true" class="octicon octicon-link"></span></a>Authenticating with SAML organizations</h3>
<p>Apps must use the <a href="/apps/building-oauth-apps/authorizing-oauth-apps/#web-application-flow">web application flow</a> to obtain OAuth tokens that work with GitHub SAML organizations. OAuth tokens created using the <a href="/v3/oauth_authorizations">Authorizations API</a> are unable to access resources for GitHub SAML organizations.</p>
<h3>
<a id="deprecating-and-adding-endpoints-for-the-oauth-authorizations-and-oauth-applications-apis" class="anchor" href="#deprecating-and-adding-endpoints-for-the-oauth-authorizations-and-oauth-applications-apis" aria-hidden="true"><span aria-hidden="true" class="octicon octicon-link"></span></a>Deprecating and adding endpoints for the OAuth Authorizations and OAuth Applications APIs</h3>
<p>GitHub is deprecating the <a href="/v3/oauth_authorizations">Authorizations API</a>, which includes these endpoints:</p>
<ul>
<li><a href="/v3/oauth_authorizations/#list-your-authorizations"><code>GET /authorizations</code></a></li>
<li><a href="/v3/oauth_authorizations/#get-a-single-authorization"><code>GET /authorizations/:authorization_id</code></a></li>
<li><a href="/v3/oauth_authorizations/#create-a-new-authorization"><code>POST /authorizations</code></a></li>
<li><a href="/v3/oauth_authorizations/#get-or-create-an-authorization-for-a-specific-app"><code>PUT /authorizations/clients/:client_id</code></a></li>
<li><a href="/v3/oauth_authorizations/#get-or-create-an-authorization-for-a-specific-app-and-fingerprint"><code>PUT /authorizations/clients/:client_id/:fingerprint</code></a></li>
<li><a href="/v3/oauth_authorizations/#update-an-existing-authorization"><code>PATCH /authorizations/:authorization_id</code></a></li>
<li><a href="/v3/oauth_authorizations/#delete-an-authorization"><code>DELETE /authorizations/:authorization_id</code></a></li>
<li><a href="/v3/oauth_authorizations/#list-your-grants"><code>GET /applications/grants</code></a></li>
<li><a href="/v3//oauth_authorizations/#get-a-single-grant"><code>GET /applications/grants/:grant_id</code></a></li>
<li><a href="/v3/oauth_authorizations/#delete-a-grant"><code>DELETE /applications/grants/:grant_id</code></a></li>
</ul>
<p>Some client-side integrations use the deprecated Authorizations API to create personal access tokens and OAuth access tokens. These tokens must now be created using our <a href="/apps/building-oauth-apps/authorizing-oauth-apps/#web-application-flow">web application flow</a>. When appropriate, personal access tokens can still be created by the user on the <a href="https://github.com/settings/tokens">Personal access tokens</a> page. However, most integrations should <a href="https://github.com/settings/applications/new">register themselves</a> as an OAuth application and use the web application flow to obtain an OAuth access token.</p>
<p>GitHub has replaced several deprecated endpoints with new ones. You can now find both the deprecated and new endpoints in the <a href="/v3/apps/oauth_applications">OAuth Applications API</a>. Specifically, we have deprecated OAuth Applications API endpoints containing an OAuth token as a path parameter:</p>
<ul>
<li><a href="/v3/apps/oauth_applications/#check-an-authorization"><code>GET /applications/:client_id/tokens/:access_token</code></a></li>
<li><a href="/v3/apps/oauth_applications/#reset-an-authorization"><code>POST /applications/:client_id/tokens/:access_token</code></a></li>
<li><a href="/v3/apps/oauth_applications/#revoke-an-authorization-for-an-application"><code>DELETE /applications/:client_id/tokens/:access_token</code></a></li>
<li><a href="/v3/apps/oauth_applications/#revoke-a-grant-for-an-application"><code>DELETE /applications/:client_id/grants/:access_token</code></a></li>
</ul>
<p>These new endpoints replace the deprecated endpoints:</p>
<ul>
<li><a href="/v3/apps/oauth_applications/#check-a-token"><code>POST /applications/:client_id/token</code></a></li>
<li><a href="/v3/apps/oauth_applications/#reset-a-token"><code>PATCH /applications/:client_id/token</code></a></li>
<li><a href="/v3/apps/oauth_applications/#delete-an-app-token"><code>DELETE /applications/:client_id/token</code></a></li>
<li><a href="/v3/apps/oauth_applications/#delete-an-app-authorization"><code>DELETE /applications/:client_id/grant</code></a></li>
</ul>
<h3>
<a id="updating-command-line-utilities-to-use-localhost-based-redirect-urls" class="anchor" href="#updating-command-line-utilities-to-use-localhost-based-redirect-urls" aria-hidden="true"><span aria-hidden="true" class="octicon octicon-link"></span></a>Updating command-line utilities to use localhost-based redirect URLs</h3>
<p>Command-line tools now support a web-based flow by using localhost-based redirect URLs and specifying a port. We have extended our support for localhost-based redirect URLs to securely improve the experience of command-line utilities for client-side integrations. Historically these tools have relied on the Authorizations API, and they have not been able to easily register an OAuth URL callback to use with our OAuth <a href="/apps/building-oauth-apps/authorizing-oauth-apps/#web-application-flow">web application flow</a>. Please see our documentation on <a href="/apps/building-oauth-apps/authorizing-oauth-apps/#localhost-redirect-urls">redirect URLs</a> for more information.</p>
<p>If you have any questions or feedback, please <a href="https://github.com/contact?form%5Bsubject%5D=Deprecated+passwords+and+authorizations+api">let us know</a>!</p>
tag:developer.github.com,2019-10-23:/changes/2019-10-23-get-installations-for-org/
<title type="html">List GitHub App installations for an organization</title>
2019-10-23T07:00:00Z
2019-10-23T07:00:00Z
<p>Now as an organization owner, you can <a href="/v3/orgs/#list-installations-for-an-organization">list all GitHub App installations</a> for an organization using the REST API. You must be an organization owner with <code>admin:read</code> scope to use this endpoint. The installation count includes all GitHub Apps installed on repositories in the organization.</p>
<pre><code>GET /orgs/:org/installations
</code></pre>
<p>To list all GitHub App installations for an organization, you must provide the <code>machine-man</code> custom <a href="/v3/media">media type</a> in the <code>Accept</code> header:</p>
<pre><code>application/vnd.github.machine-man-preview+json
</code></pre>
<p>During the preview period, we may change aspects of these APIs based on developer feedback.</p>
<p>If we do, we will announce the changes here on the developer blog, but we will not provide any advance notice. If you have any questions or feedback, <a href="https://github.com/contact?form%5Bsubject%5D=Feedback:+Listing+GitHub+App+installations+for+an+organization+via+the+API">let us know</a>.</p>
tag:developer.github.com,2019-10-04:/changes/2019-10-04-end-mister-fantastic-preview/
<title type="html">GitHub Pages features become an official part of the REST API</title>
2019-10-04T07:00:00Z
2019-10-04T07:00:00Z
<p>The features that are a part of the GitHub Pages <code>mister-fantastic-preview</code> are now available on GitHub.com and will be available in the next versions of GitHub Enterprise (2.19 and higher). You will no longer need to pass a preview header to use most GitHub Pages API endpoints.</p>
<h3>
<a id="preview-media-type-no-longer-needed" class="anchor" href="#preview-media-type-no-longer-needed" aria-hidden="true"><span aria-hidden="true" class="octicon octicon-link"></span></a>Preview media type no longer needed</h3>
<p>Now that the preview period has ended (first announced in <a href="/changes/2016-07-06-github-pages-preview-api/">July 2016</a>), you no longer need to pass the <code>mister-fantastic-preview</code> custom media type. Instead, we recommend that you specify v3 as the version in the Accept header:</p>
<pre><code>application/vnd.github.v3+json
</code></pre>
<p>Please note that if you use GitHub Enterprise versions 2.8 to 2.18, you will still need to provide this custom media type in the Accept header:</p>
<pre><code>application/vnd.github.mister-fantastic-preview+json
</code></pre>
<p><strong><em>Onward!</em></strong>
Thanks again to everyone that tried out these GitHub Pages API features during the preview period.</p>
tag:developer.github.com,2019-10-03:/changes/2019-10-03-multi-line-comments/
<title type="html">Multi-line comments</title>
2019-10-03T07:00:00Z
2019-10-03T07:00:00Z
<p>Now you can create comments across multiple lines of code in a pull request diff using REST API or GraphQL.</p>
<p>To create multi-line comments or see multi-line comments with the new supported fields when you fetch comment responses, you must provide a custom <a href="/v3/media">media type</a> in the <code>Accept</code> header:</p>
<pre><code>application/vnd.github.comfort-fade-preview+json
</code></pre>
<p>During the preview period, we may change aspects of these APIs based on developer feedback.</p>
<p>If we do, we will announce the changes here on the developer blog, but we will not provide any advance notice. If you have any questions or feedback, <a href="https://github.com/contact?form%5Bsubject%5D=Feedback%3A+API+support+for+Multi-line+comments">please let us know</a>.</p>
tag:developer.github.com,2019-09-24:/changes/2019-09-24-team-sychronization-end-preview/
<title type="html">Team sychronization become an official part of REST API</title>
2019-09-24T07:00:00Z
2019-09-24T07:00:00Z
<p>The features that are a part of the team sychronization <code>team-sync-preview</code> are now available on GitHub.com. Going forward, the Team synchronization API endpoints will be available without a preview header.</p>
<h3>
<a id="preview-media-type-no-longer-needed" class="anchor" href="#preview-media-type-no-longer-needed" aria-hidden="true"><span aria-hidden="true" class="octicon octicon-link"></span></a>Preview media type no longer needed</h3>
<p>Now that the preview period has ended (first announced in <a href="/changes/2019-06-12-team-sync/">June 2019</a>), you no longer need to pass the <code>team-sync-preview</code> custom media type.</p>
tag:developer.github.com,2019-09-06:/changes/2019-09-06-more-check-annotations-shown-in-files-changed-tab/
<title type="html">More check annotations are now shown on the "Files changed" tab</title>
2019-09-06T07:00:00Z
2019-09-06T07:00:00Z
<p>In May of 2018, we <a href="/changes/2018-05-07-new-checks-api-public-beta/">announced the Checks API</a>, which added many new capabilities for running checks on code. One of those new capabilities were check annotations, which let apps annotate specific lines of code as part of a check run.</p>
<p><img src="https://user-images.githubusercontent.com/7718702/60444186-9d121e00-9c14-11e9-9c51-d62791d5d317.png" alt="demo-screenshot-of-unchanged-files-with-check-annotations"></p>
<p>Check annotations point directly to those lines where a test failure or a lint error occurred, and they empower users to fix any kind of errors or warnings quickly so they can move forward with their pull requests.</p>
<p><img src="/assets/images/checks/checks_annotation.png" alt="demo-screenshot-from-checks-api-blog-post"></p>
<p>Today we're making check annotations even more powerful by bringing more of them to where you're already looking: the "Files changed" tab. Checks annotations created on lines or files that were <strong>not</strong> modified as part of a pull request will now be prominently displayed alongside the diff.</p>
<p>Internal testing has proven that surfacing unchanged files with check annotations has been especially beneficial to our workflows, because test failures can often happen on files that weren't modified as part of a pull request.</p>
<p><a href="https://github.com/wilhelmklopp/failing-test-annotation/pull/2/files">Click here to see it in action!</a></p>
<p>The best part? The <a href="/v3/checks/runs/#annotations-object">API for creating check annotations</a> has not changed. If you're already creating annotations on files or lines outside of the diff, then there's no need to modify any code to use this improvement.</p>
<p>If you have any questions or feedback, please <a href="https://github.com/contact?form%5Bsubject%5D=Feedback:+More+check+annotations+are+now+shown+on+the+Files+changed+tab">let us know.</a></p>
tag:developer.github.com,2019-09-05:/changes/2019-09-05-apps-protected-branches-api/
<title type="html">Grant GitHub Apps push access to protected branches</title>
2019-09-05T07:00:00Z
2019-09-05T07:00:00Z
<p>The <a href="/v3/repos/branches/">Protected Branches API</a> now allows you to grant GitHub Apps push access to protected branches.</p>
<p>You can only grant GitHub Apps push access to a protected branch if they have been installed with the repository contents <code>write</code> permission.</p>
<p>The Protected Branches API now includes the following endpoints:</p>
<ul>
<li><a href="/v3/repos/branches/#list-apps-with-access-to-protected-branch"><code>GET /repos/:owner/:repo/branches/:branch/protection/restrictions/apps</code></a></li>
<li><a href="/v3/repos/branches/#replace-app-restrictions-of-protected-branch"><code>PUT /repos/:owner/:repo/branches/:branch/protection/restrictions/apps</code></a></li>
<li><a href="/v3/repos/branches/#add-app-restrictions-of-protected-branch"><code>POST /repos/:owner/:repo/branches/:branch/protection/restrictions/apps</code></a></li>
<li><a href="/v3/repos/branches/#remove-app-restrictions-of-protected-branch"><code>DELETE /repos/:owner/:repo/branches/:branch/protection/restrictions/apps</code></a></li>
</ul>
<p>The existing endpoint to set branch protection now accepts app restrictions:</p>
<ul>
<li><a href="/v3/repos/branches/#update-branch-protection"><code>PUT /repos/:owner/:repo/branches/:branch/protection</code></a></li>
</ul>
<p>If you have any questions or feedback, please <a href="https://github.com/contact?form%5Bsubject%5D=Apps+Protected+Branchess">get in touch</a>!</p>
tag:developer.github.com,2019-07-16:/changes/2019-07-16-repository-templates-api/
<title type="html">Create and use repository templates</title>
2019-07-16T07:00:00Z
2019-07-16T07:00:00Z
<p>Repository templates enable you to create a new repository using an existing one that is marked <code>is_template</code>. This only copies repository contents without copying the commit history.</p>
<p>To access the new API, you must provide a custom media type in the Accept header:</p>
<pre><code>application/vnd.github.baptiste-preview+json
</code></pre>
<p>The following new endpoint is available for you to generate a new repository from a template repository:</p>
<ul>
<li><a href="/v3/repos/#create-repository-using-a-repository-template"><code>POST /repos/:owner/:repo/generate</code></a></li>
</ul>
<p>In addition, you can make your repository available as a template when you <a href="/v3/repos/#create">Create</a> or <a href="/v3/repos/#edit">Edit</a> the repository. You can also <a href="/v3/repos/#get">GET</a> a repository's information to see if the repository is available to use as a template (<code>is_template</code> key is <code>true</code>) or was generated from a <code>template_repository</code>. For more information, see the <a href="/v3/repos/">Repositories API</a>.</p>
<p>During the preview period, we may change aspects of these APIs based on developer feedback.
If we do, we will announce the changes here on the developer blog, but we will not provide any advance notice.</p>
<p>If you have any questions or feedback, please <a href="https://github.com/contact?form%5Bsubject%5D=baptiste+preview">let us know</a>!</p>
tag:developer.github.com,2019-06-12:/changes/2019-06-12-team-sync/
<title type="html">Connect GitHub teams and IdP groups</title>
2019-06-12T07:00:00Z
2019-06-12T07:00:00Z
<div class="alert product"><p>
Team synchronization is available for organizations using GitHub Enterprise Cloud. For more information, see <a href="https://help.github.com/articles/github-s-products">GitHub's products</a> in the GitHub Help documentation.
</p></div>
<p>The <a href="/v3/teams/team_sync/">Team Synchronization API</a> allows you to manage connections between GitHub teams and external identity provider (IdP) groups.</p>
<p>You can manage GitHub team members through your IdP with team synchronization. Team synchronization must be enabled to use the Team Synchronization API. For more information, see "<a href="https://help.github.com/articles/synchronizing-teams-between-your-identity-provider-and-github/">Synchronizing teams between your identity provider and GitHub</a>" in the GitHub Help documentation.</p>
<p>To access the new API, you will need to <a href="https://help.github.com/en/articles/authorizing-a-personal-access-token-for-use-with-a-saml-single-sign-on-organization">authorize your API token</a> for use with your IdP (SSO) provider. You must also provide a custom media type in the Accept header:</p>
<pre><code>application/vnd.github.team-sync-preview+json
</code></pre>
<p>The following endpoints in the <a href="/v3/teams/team_sync/">Team Synchronization API</a> are available for you to use:</p>
<ul>
<li><code>GET /orgs/:org/team-sync/groups</code></li>
<li><code>GET /teams/:team_id/team-sync/group-mappings</code></li>
<li><code>PATCH /teams/:team_id/team-sync/group-mappings</code></li>
</ul>
<p>During the preview period, we may change aspects of these APIs based on developer feedback.
If we do, we will announce the changes here on the developer blog, but we will not provide any advance notice.</p>
<p>If you have any questions or feedback, please <a href="https://github.com/contact?form%5Bsubject%5D=team+sync+preview">let us know</a>!</p>
tag:developer.github.com,2019-06-04:/changes/2019-06-04-automated-security-fixes/
<title type="html">Enable or disable automated security fixes for a repository</title>
2019-06-04T07:00:00Z
2019-06-04T07:00:00Z
<p>Previously, you could only enable or disable automated security fixes from a repository's security alerts page. We understand that having to do this for a large amount of repositories is not an optimal user experience. We've heard your feedback and are pleased to announce that we have released a new set of endpoints to manage the automated security fixes setting for your repositories.</p>
<p>To access the new endpoints, you must provide a custom media type in the Accept header:</p>
<pre><code>application/vnd.github.london-preview+json
</code></pre>
<p>The first endpoint allows you to <a href="/v3/repos/#enable-automated-security-fixes">enable</a> the automated security fixes setting:</p>
<pre><code>PUT /repos/:owner/:repo/automated-security-fixes
</code></pre>
<p>The second endpoint allows you to <a href="/v3/repos/#disable-automated-security-fixes">disable</a> the automated security fixes setting:</p>
<pre><code>DELETE /repos/:owner/:repo/automated-security-fixes
</code></pre>
<p>During the preview period, we may change aspects of these APIs based on developer feedback.
If we do, we will announce the changes here on the developer blog, but we will not provide any advance notice.</p>
<p>If you have any questions or feedback, please <a href="https://github.com/contact?form%5Bsubject%5D=london+preview">let us know</a>!</p>
tag:developer.github.com,2019-05-29:/changes/2019-05-29-update-branch-api/
<title type="html">Perform an "Update branch" on a pull request via the REST API</title>
2019-05-29T07:00:00Z
2019-05-29T07:00:00Z
<p>We are pleased to announce a new API for updating the branch on a pull request, the <strong>Update Branch API</strong>. Rather than having to manually click a button to update the HEAD of a pull request branch with the latest changes from the base branch, you can now do so with one REST API endpoint call.</p>
<p>Why not just use the <a href="/v3/repos/merging/#perform-a-merge">Merging API</a>? Good question, and of course you can! The advantage of using this new API is that you only need the pull request number, not the <code>base</code> or <code>head</code>. This could potentially save a few roundtrips to the API and reduce the risk of getting rate limited.</p>
<p>To access the new endpoints, you must provide a custom media type in the Accept header:</p>
<pre><code>application/vnd.github.lydian-preview+json
</code></pre>
<p>The <a href="/v3/pulls/#update-a-pull-request-branch">update a pull request branch</a> endpoint allows you to update the HEAD of the pull request branch for a pull request.</p>
<pre><code>PUT /repos/:owner/:repo/pulls/:pull_number/update-branch
</code></pre>
<p>During the preview period, we may change aspects of these APIs based on developer feedback.
If we do, we will announce the changes here on the developer blog, but we will not provide any advance notice.</p>
<p>Feedback <a href="https://github.com/contact?form%5Bsubject%5D=lydian+preview">welcomed</a>!</p>
tag:developer.github.com,2019-04-24:/changes/2019-04-24-vulnerability-alerts/
<title type="html">Enable or disable vulnerability alerts for a repository</title>
2019-04-24T07:00:00Z
2019-04-24T07:00:00Z
<p>Previously, you could only enable or disable repository vulnerability alerts by checking a box in a repository's settings. We understand that having to do this for a large amount of repositories is not an optimal user experience. We've heard your feedback and are pleased to announce that we have released a new set of endpoints to manage the vulnerability alerts setting for your repositories.</p>
<p>To access the new endpoints, you must provide a custom media type in the Accept header:</p>
<pre><code>application/vnd.github.dorian-preview+json
</code></pre>
<p>The first endpoint allows you to <a href="/v3/repos/#enable-vulnerability-alerts">enable</a> the vulnerability alerts setting:</p>
<pre><code>PUT /repos/:owner/:repo/vulnerability-alerts
</code></pre>
<p>And the second endpoint allows you to <a href="/v3/repos/#disable-vulnerability-alerts">disable</a> the vulnerability alerts setting:</p>
<pre><code>DELETE /repos/:owner/:repo/vulnerability-alerts
</code></pre>
<p>During the preview period, we may change aspects of these APIs based on developer feedback.
If we do, we will announce the changes here on the developer blog, but we will not provide any advance notice.</p>
<p>If you have any questions or feedback, please <a href="https://github.com/contact?form%5Bsubject%5D=dorian+preview">let us know</a>!</p>
<p><strong><em>[Updated 06-10-19]</em></strong> You can also <a href="/v3/repos/#check-if-vulnerability-alerts-are-enabled-for-a-repository">check whether repository alerts are enabled or disabled</a> for a repository using a new endpoint.</p>
<pre><code> GET /repos/:owner/:repo/vulnerability-alerts
</code></pre>
tag:developer.github.com,2019-04-18:/changes/2019-04-18-new-webhook-events-and-actions/
<title type="html">New webhook events and actions</title>
2019-04-18T07:00:00Z
2019-04-18T07:00:00Z
<p>Our webhooks team is pleased to announce that we have added some long-awaited webhook events and actions to the list that we support and they will be available today. You'll automatically begin receiving these events if you have a webhook that is subscribed to <a href="/webhooks/#wildcard-event">wildcard</a> events, otherwise you will be able to select the new events from the list in your webhook settings. As always, we continue to <a href="/changes/2016-03-15-new-webhook-actions/#how-to-work-with-new-event-actions">recommend listening for the actions</a> in order to future-proof your code.</p>
<p>Here are the new events and actions that we've added:</p>
<table>
<thead>
<tr>
<th>Event</th>
<th>Action</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td><a href="/v3/activity/events/types#deploykeyevent"><code>DeployKeyEvent</code></a></td>
<td><code>created</code></td>
<td>Triggered when a deploy key is added to a repository.</td>
</tr>
<tr>
<td><a href="/v3/activity/events/types#deploykeyevent"><code>DeployKeyEvent</code></a></td>
<td><code>deleted</code></td>
<td>Triggered when a deploy key is removed from a repository.</td>
</tr>
<tr>
<td><a href="/v3/activity/events/types#issuesevent"><code>IssueEvent</code></a></td>
<td><code>locked</code></td>
<td>Triggered when an issue is locked.</td>
</tr>
<tr>
<td><a href="/v3/activity/events/types#issuesevent"><code>IssueEvent</code></a></td>
<td><code>unlocked</code></td>
<td>Triggered when an issue is unlocked.</td>
</tr>
<tr>
<td><a href="/v3/activity/events/types#metaevent"><code>MetaEvent</code></a></td>
<td><code>deleted</code></td>
<td>Triggered when the hook itself is deleted.</td>
</tr>
<tr>
<td><a href="/v3/activity/events/types#organizationevent"><code>OrganizationEvent</code></a></td>
<td><code>renamed</code></td>
<td>Triggered when the organization is renamed.</td>
</tr>
<tr>
<td><a href="/v3/activity/events/types#organizationevent"><code>OrganizationEvent</code></a></td>
<td><code>deleted</code></td>
<td>Triggered when the organization is deleted.</td>
</tr>
<tr>
<td><a href="/v3/activity/events/types#pullrequestevent"><code>PullRequestEvent</code></a></td>
<td><code>locked</code></td>
<td>Triggered when a pull request is locked.</td>
</tr>
<tr>
<td><a href="/v3/activity/events/types#pullrequestevent"><code>PullRequestEvent</code></a></td>
<td><code>unlocked</code></td>
<td>Triggered when a pull request is unlocked.</td>
</tr>
<tr>
<td><a href="/v3/activity/events/types#releaseevent"><code>ReleaseEvent</code></a></td>
<td><code>created</code></td>
<td>Triggered when a release is created.</td>
</tr>
<tr>
<td><a href="/v3/activity/events/types#releaseevent"><code>ReleaseEvent</code></a></td>
<td><code>edited</code></td>
<td>Triggered when a release is edited.</td>
</tr>
<tr>
<td><a href="/v3/activity/events/types#releaseevent"><code>ReleaseEvent</code></a></td>
<td><code>deleted</code></td>
<td>Triggered when a release is deleted.</td>
</tr>
<tr>
<td><a href="/v3/activity/events/types#releaseevent"><code>ReleaseEvent</code></a></td>
<td><code>prereleased</code></td>
<td>Triggered when a release is prereleased.</td>
</tr>
<tr>
<td><a href="/v3/activity/events/types#releaseevent"><code>ReleaseEvent</code></a></td>
<td><code>unpublished</code></td>
<td>Triggered when a release is unpublished.</td>
</tr>
<tr>
<td><a href="/v3/activity/events/types#repositoryevent"><code>RepositoryEvent</code></a></td>
<td><code>edited</code></td>
<td>Triggered when attributes on a repository (e.g. description, default branch, homepage) are changed.</td>
</tr>
<tr>
<td><a href="/v3/activity/events/types#repositoryevent"><code>RepositoryEvent</code></a></td>
<td><code>renamed</code></td>
<td>Triggered when a repository is renamed.</td>
</tr>
<tr>
<td><a href="/v3/activity/events/types#repositoryevent"><code>RepositoryEvent</code></a></td>
<td><code>transferred</code></td>
<td>Triggered when a repository is transferred to a new owner.</td>
</tr>
<tr>
<td><a href="/v3/activity/events/types#starevent"><code>StarEvent</code></a></td>
<td><code>created</code></td>
<td>Triggered when a star is added to a repository.</td>
</tr>
<tr>
<td><a href="/v3/activity/events/types#starevent"><code>StarEvent</code></a></td>
<td><code>deleted</code></td>
<td>Triggered when a star is removed from a repository.</td>
</tr>
</tbody>
</table>
<p>Please visit our <a href="/webhooks">webhooks documentation</a> to view all of the events and actions that we support, and to get more information on these new ones.</p>
<p>If you have any questions or feedback, please <a href="https://github.com/contact?form%5Bsubject%5D=New+Webhook+Events">get in touch</a>!</p>
tag:developer.github.com,2019-04-11:/changes/2019-04-11-pulls-branches-for-commit/
<title type="html">List branches or pull requests for a commit (preview)</title>
2019-04-11T07:00:00Z
2019-04-11T07:00:00Z
<p>We're releasing a couple of REST endpoints that enable you to retrieve additional information from an existing commit.</p>
<p>To access the new endpoints you must provide a custom media type in the Accept header:</p>
<pre><code>application/vnd.github.groot-preview+json
</code></pre>
<p>The first endpoint allows you to <a href="/v3/repos/commits/#list-branches-for-head-commit">get the list of branches</a> where the given commit is the <code>HEAD</code>:</p>
<pre><code>GET /repos/:owner/:repo/commits/:commit_sha/branches-where-head
</code></pre>
<p>The second one enables you to <a href="/v3/repos/commits/#list-pull-requests-associated-with-commit">get a list of pull requests</a> associated with the commit:</p>
<pre><code>GET /repos/:owner/:repo/commits/:commit_sha/pulls
</code></pre>
<p>During the preview period, we may change aspects of these APIs based on developer feedback.
If we do, we will announce the changes here on the developer blog, but we will not provide any advance notice.</p>
<p>If you have any questions or feedback, please <a href="https://github.com/contact?form%5Bsubject%5D=Groot+preview">let us know</a>!</p>
tag:developer.github.com,2019-03-29:/changes/2019-03-29-webhooks-ip-changes/
<title type="html">Webhook IP addresses are changing</title>
2019-03-29T07:00:00Z
2019-03-29T07:00:00Z
<p>On April 9th, GitHub will begin sending webhooks from the <code>140.82.112.0/20</code> range of IP addresses in addition to the older <code>192.30.252.0/22</code> range.</p>
<p>We use a large pool of IP's to reach our customers, and we are adding further netblocks to help serve webhooks more reliably. If you have rules in place that only allow GitHub webhooks from our trusted addresses, you will need to update them.</p>
<p>This block of IPs has been in the <a href="https://help.github.com/en/articles/about-githubs-ip-addresses">/meta</a> API endpoint since May 2018, but we wanted to announce this update in case you missed it.</p>
<p>Please <a href="https://github.com/contact?form%5Bsubject%5D=Webhooks+IPs+Are+Changing">contact us</a> if you have any questions.</p>
tag:developer.github.com,2019-03-26:/changes/2019-03-26-new-response-code-for-notifications-marked-as-read-in-bulk/
<title type="html">New response code for notifications marked as "read" in bulk</title>
2019-03-26T07:00:00Z
2019-03-26T07:00:00Z
<p>You can use the <a href="/v3/activity/notifications/#mark-as-read"><code>/PUT notifications</code></a> endpoint to mark all notifcations as "read." Similarly, you can use the <a href="/v3/activity/notifications/#mark-notifications-as-read-in-a-repository"><code>PUT /repos/:owner/:repo/notifications</code></a> endpoint to mark all notifications as "read" for a specific repository.</p>
<p>Sometimes, GitHub would time out and return an error when there were too many unread notifications to process in a single request. We've changed both endpoints to trigger a background job that will mark the notifications as "read" asynchronously. If the operation is too expensive for a single request, the endpoint returns a <code>202</code> status code with the following response:</p>
<pre class="highlight highlight-json"><code><span class="p">{</span><span class="w">
</span><span class="nt">"message"</span><span class="p">:</span><span class="w"> </span><span class="s2">"Unread notifications couldn't be marked in a single request. Notifications are being marked as read in the background."</span><span class="w">
</span><span class="p">}</span><span class="w">
</span></code></pre>
<p>After analyzing recent request data and we expect very few requests to trigger a background job. Most requests should return a <code>205</code> status code as usual. If you do receive a <code>202</code> status code, it will take a short amount of time for all notifications to be marked as "read" in the background job. There is currently no way to check if the job has completed. Instead, we recommend checking the number of unread notifications in separate requests using one of these endpoints:</p>
<pre><code>GET https://api.github.com/notifications?all=false
</code></pre>
<p>or</p>
<pre><code>GET https://api.github.com/repos/:owner/:repo/notifications?all=false
</code></pre>
tag:developer.github.com,2019-03-14:/changes/2019-03-14-enabling-disabling-pages/
<title type="html">Preview enable and disable Pages API endpoints</title>
2019-03-14T07:00:00Z
2019-03-14T07:00:00Z
<p>We're releasing a new Pages API preview that allows you to enable and disable GitHub Pages from the REST v3 API. These add to our existing Pages APIs which allow you to access & update Pages configuration as well as access & create new builds.</p>
<p>To access the <a href="/v3/repos/pages/#enable-a-pages-site">enable API</a> or <a href="/v3/repos/pages/#disable-a-pages-site">disable API</a> during the preview period, you must provide a custom <a href="/v3/media">media type</a> in the <code>Accept</code> header:</p>
<pre><code> application/vnd.github.switcheroo-preview+json
</code></pre>
<p>During the preview period, we may change aspects of these APIs based on developer feedback.
If we do, we will announce the changes here on the developer blog, but we will not provide any advance notice.</p>
<p>If you have any questions or feedback, please <a href="https://github.com/contact?form%5Bsubject%5D=Pages+toggle+API">let us know</a>!</p>
tag:developer.github.com,2019-02-14:/changes/2019-02-14-draft-pull-requests/
<title type="html">Preview the new Draft Pull Requests API</title>
2019-02-14T08:00:00Z
2019-02-14T08:00:00Z
<div class="alert product"><p>
Draft pull requests are available in public repositories with GitHub Free and GitHub Pro, and in public and private repositories with GitHub Team and GitHub Enterprise Cloud. For more information, see <a href="https://help.github.com/articles/github-s-billing-plans">GitHub's billing plans</a> in the GitHub Help documentation.
</p></div>
<p>We're releasing new GraphQL mutations and fields that allow you to handle draft pull requests. We're also showing the <code>draft</code> boolean in REST API responses. When this boolean is <code>true</code>, the pull request is in a draft state, and cannot be merged. For more information about draft pull requests, see "<a href="https://help.github.com/articles/about-pull-requests/">About pull requests</a>" in the GitHub Help documentation.</p>
<p><strong><em>[Updated 03-22-19]</em></strong> You can also create draft pull requests using a new <code>draft</code> field in the <a href="/v3/pulls/#create-a-pull-request">Create a pull request</a> endpoint. </p>
<h3>
<a id="changes" class="anchor" href="#changes" aria-hidden="true"><span aria-hidden="true" class="octicon octicon-link"></span></a>Changes</h3>
<ul>
<li><a href="/v3/pulls/">REST API pull request responses include <code>draft</code> boolean</a></li>
<li><a href="/v4/input_object/createpullrequestinput/"><code>CreatePullRequestInput</code> includes <code>draft</code> boolean</a></li>
<li><a href="/v4/mutation/markpullrequestreadyforreview/"><code>markPullRequestReadyForReview</code> mutation</a></li>
<li><a href="/v4/object/pullrequest/#fields"><code>PullRequest</code> object includes <code>draft</code> field</a></li>
</ul>
<p>To access these new API endpoints during the preview period, you must provide a custom <a href="/v3/media">media type</a> in the <code>Accept</code> header:</p>
<pre><code>application/vnd.github.shadow-cat-preview+json
</code></pre>
<p>During the preview period, we may change aspects of these API endpoints based on developer feedback.
If we do, we will announce the changes here on the developer blog, but we will not provide any advance notice.</p>
<p>If you have any questions or feedback, please <a href="https://github.com/contact?form%5Bsubject%5D=Draft+PR+API+Preview">let us know</a>!</p>
tag:developer.github.com,2019-01-31:/changes/2019-01-31-removing-speedy-preview/
<title type="html">Removing the strict validation preview</title>
2019-01-31T08:00:00Z
2019-01-31T08:00:00Z
<p>As part of our plans for stricter validation in our REST API, we <a href="/changes/2018-09-26-pass-header-to-test-strict-validation-in-rest-api/">introduced</a> a preview header to test out the changes before the rollout. Stricter validation has been <a href="/changes/2018-11-07-strict-validation/">postponed</a> and beginning January 31, 2019, we will no longer support this header:</p>
<pre><code>application/vnd.github.speedy-preview+json
</code></pre>
<p>We still believe that stricter validation would have a positive impact on our REST API overall and are looking for alternative ways to introduce it. Stay tuned for future updates.</p>
<p>If you have any questions, please <a href="https://github.com/contact?form%5Bsubject%5D=Strict+validation+in+REST+API">reach out</a>!</p>
tag:developer.github.com,2019-01-29:/changes/2019-01-29-life-after-github-services/
<title type="html">"GitHub Services" Feature Deprecation: What to Expect</title>
2019-01-29T08:00:00Z
2019-01-29T08:00:00Z
<p>As we have mentioned in previous posts, the "GitHub Services" feature will be deprecated <em>this Thursday</em>, <strong>January 31st, 2019</strong>. Here is what you can expect regarding "GitHub Services" going forward:</p>
<ul>
<li>GitHub will cut off all service hook deliveries. There will be no exceptions or extensions. If you still have service hooks configured for your repositories, we highly suggest migrating them to <a href="/webhooks/">webhooks</a> or <a href="/apps/">GitHub Apps</a>. Please see our "<a href="/v3/guides/replacing-github-services/">Replacing GitHub Services</a>" guide for more information on how to do that.</li>
<li>The <a href="https://github.com/github/github-services"><code>github/github-services</code></a> repository will be <strong>archived</strong> and no more contributions to the services will be accepted.</li>
<li>You will no longer be able to modify service hook configurations through the GitHub settings UI or the repository hooks API. This change will affect the following endpoints for <em>service hooks only</em>:
<ul>
<li><a href="/v3/repos/hooks/#edit-a-hook"><code>PATCH /repos/:owner/:repo/hooks/:hook_id</code></a></li>
<li><a href="/v3/repos/hooks/#test-a-push-hook"><code>POST /repos/:owner/:repo/hooks/:hook_id/tests</code></a></li>
<li><a href="/v3/repos/hooks/#ping-a-hook"><code>POST /repos/:owner/:repo/hooks/:hook_id/pings</code></a></li>
</ul>
</li>
<li>You will still be able to view and remove service hooks through the GitHub settings UI and API until <strong>April 1st, 2019</strong>. After that date, we will be removing all service hook records.</li>
<li>
<strong><em>Updated 01-30-19</em></strong>: Email service hooks have been migrated to a new repository notifications feature. Management of those notifications can be found in the repository settings UI <em>only</em>. There are no necessary actions to be taken to enable this new feature, and there should be no interruption of service for email deliveries. See "<a href="https://help.github.com/articles/about-email-notifications-for-pushes-to-your-repository/">About email notifications for pushes to your repository</a>" in the GitHub Help documentation to learn how to configure commit email notifications. Email notifications for pushes to your repository will be available in GitHub Enterprise Server 2.17 and higher.</li>
</ul>
<div class="alert note">
<p><strong>Note</strong>: The "GitHub Services" feature has a different deprecation timeline for GitHub Enterprise. Please see our <a href="/v3/guides/replacing-github-services/#supporting-github-enterprise-server">deprecation timeline</a> for more information.</p>
</div>
<p>Please <a href="https://github.com/contact?form%5Bsubject%5D=GitHub+Services+Deprecation">contact us</a> if you have any questions!</p>
tag:developer.github.com,2018-12-18:/changes/2018-12-18-interactions-preview/
<title type="html">Preview the new Interactions API</title>
2018-12-18T08:00:00Z
2018-12-18T08:00:00Z
<p>We're releasing new REST API v3 endpoints that allow you to manage <a href="https://help.github.com/articles/limiting-interactions-in-your-repository/">repository</a> and <a href="https://help.github.com/articles/limiting-interactions-in-your-organization/">organization</a> interaction limits.</p>
<h4>
<a id="new-endpoints" class="anchor" href="#new-endpoints" aria-hidden="true"><span aria-hidden="true" class="octicon octicon-link"></span></a>New endpoints</h4>
<ul>
<li><a href="/v3/interactions/repos/#get-interaction-restrictions-for-a-repository">Get interaction restrictions for a repository</a></li>
<li><a href="/v3/interactions/repos/#add-or-update-interaction-restrictions-for-a-repository">Add or update interaction restrictions for a repository</a></li>
<li><a href="/v3/interactions/repos/#remove-interaction-restrictions-for-a-repository">Remove interaction restrictions for a repository</a></li>
<li><a href="/v3/interactions/orgs/#get-interaction-restrictions-for-an-organization">Get interaction restrictions for an organization</a></li>
<li><a href="/v3/interactions/orgs/#add-or-update-interaction-restrictions-for-an-organization">Add or update interaction restrictions for an organization</a></li>
<li><a href="/v3/interactions/orgs/#remove-interaction-restrictions-for-an-organization">Remove interaction restrictions for an organization</a></li>
</ul>
<p>To access these new API endpoints during the preview period, you must provide a custom <a href="/v3/media">media type</a> in the <code>Accept</code> header:</p>
<pre><code>application/vnd.github.sombra-preview+json
</code></pre>
<p>During the preview period, we may change aspects of these API endpoints based on developer feedback.
If we do, we will announce the changes here on the developer blog, but we will not provide any advance notice.</p>
<p>If you have any questions or feedback, please <a href="https://github.com/contact?form%5Bsubject%5D=Interactions+API+Preview">let us know</a>!</p>
tag:developer.github.com,2018-12-18:/changes/2018-12-18-content-attachments-api-time-limit/
<title type="html">Creating Content Attachments Limited to 6 Hours</title>
2018-12-18T08:00:00Z
2018-12-18T08:00:00Z
<p>In an effort to provide a predictable user experience, we are going to begin limiting the creation of content attachments to 6 hours from when the content reference URL was added.</p>
<p>If an application tries to create a content attachment for a content reference URL older than 6 hours, a response with HTTP status code <code>422</code> will be returned.</p>
<p>Please <a href="https://github.com/contact?form%5Bsubject%5D=Creating%20Content%20Attachments%20Limited%20to%206%20Hours">contact us</a> if you have any questions!</p>
tag:developer.github.com,2018-12-10:/changes/2018-12-10-content-attachments-api/
<title type="html">Content Attachments API Public Beta</title>
2018-12-10T08:00:00Z
2018-12-10T08:00:00Z
<p>Developers share a lot of links on GitHub. Nearly one-third of comments on issues and pull requests include a link. Hidden behind each of those links is important context that can inform the conversation. Today we’re excited to announce that you can curate and showcase content to help drive those conversations with the <strong>Content Attachments API</strong>, which is now in public beta.</p>
<p>GitHub Apps now have the ability to listen for links in issues and pull requests and attach content to those links:</p>
<p><img src="https://user-images.githubusercontent.com/7718702/49523156-188b3700-f8a1-11e8-8c08-9bfbdd9119b5.png" alt="demo screenshot"></p>
<h1>
<a id="setting-up-content-attachments" class="anchor" href="#setting-up-content-attachments" aria-hidden="true"><span aria-hidden="true" class="octicon octicon-link"></span></a>Setting up content attachments</h1>
<p><strong>Step 1.</strong> <a href="https://github.com/settings/apps/new">Create a GitHub App</a>.</p>
<p>Register the domain that your app would like to create content attachments for (errors.ai in this case). Make sure to select <strong>Read & write</strong> access:
<img src="https://user-images.githubusercontent.com/7718702/49523374-918a8e80-f8a1-11e8-959a-7c2e8d8b8cba.png" alt="content references permission">
Make sure to select the <strong>Content reference</strong> event:
<img src="https://user-images.githubusercontent.com/7718702/49523475-c696e100-f8a1-11e8-812a-edff499106d0.png" alt="content reference event"></p>
<p><strong>Step 2.</strong> Install your newly created GitHub App on a repository.</p>
<h1>
<a id="api-interaction-flow" class="anchor" href="#api-interaction-flow" aria-hidden="true"><span aria-hidden="true" class="octicon octicon-link"></span></a>API interaction flow</h1>
<ol>
<li><p>Someone posts a link in an issue or pull request on a repository where your app is installed.</p></li>
<li>
<p>Your app will receive a <code>content_reference</code> event with action <code>created</code>. The contents of the <code>content_reference</code> and <code>installation</code> hash are important.</p>
<pre class="highlight highlight-json"><code><span class="p">{</span><span class="w">
</span><span class="nt">"action"</span><span class="p">:</span><span class="w"> </span><span class="s2">"created"</span><span class="p">,</span><span class="w">
</span><span class="nt">"content_reference"</span><span class="p">:</span><span class="w"> </span><span class="p">{</span><span class="w">
</span><span class="nt">"id"</span><span class="p">:</span><span class="w"> </span><span class="mi">1512</span><span class="p">,</span><span class="w">
</span><span class="nt">"node_id"</span><span class="p">:</span><span class="w"> </span><span class="s2">"MDE2OkNvbnRlbnRSZWZlcmVuY2UxNTEy"</span><span class="p">,</span><span class="w">
</span><span class="nt">"reference"</span><span class="p">:</span><span class="w"> </span><span class="s2">"https://errors.ai/my-project/A-1234"</span><span class="w">
</span><span class="p">},</span><span class="w">
</span><span class="nt">"repository"</span><span class="p">:</span><span class="w"> </span><span class="p">{</span><span class="err">...</span><span class="p">},</span><span class="w">
</span><span class="nt">"sender"</span><span class="p">:</span><span class="w"> </span><span class="p">{</span><span class="err">...</span><span class="p">},</span><span class="w">
</span><span class="nt">"installation"</span><span class="p">:</span><span class="w"> </span><span class="p">{</span><span class="w">
</span><span class="nt">"id"</span><span class="p">:</span><span class="w"> </span><span class="mi">492164</span><span class="p">,</span><span class="w">
</span><span class="nt">"node_id"</span><span class="p">:</span><span class="w"> </span><span class="s2">"MDIzOkludGVncmF0aW9uSW5zdGFsbGF0aW9uNDkyMTY0"</span><span class="w">
</span><span class="p">}</span><span class="w">
</span><span class="p">}</span><span class="w">
</span></code></pre>
</li>
<li>
<p>Using the <code>content_reference</code> <code>id</code> you can now create a content attachment using the API by supplying a <code>title</code> and <code>body</code> in the API call. You'll also need the <code>installation</code> <code>id</code> to authenticate as a <a href="/apps/building-github-apps/authenticating-with-github-apps/#authenticating-as-an-installation">GitHub App installation</a>. You can use markdown in the <code>body</code> parameter.</p>
<pre class="highlight highlight-curl"><code>curl -X POST
https://api.github.com/content_references/1512/attachments
-H 'Accept: application/vnd.github.corsair-preview+json'
-H 'Authorization: Bearer $INSTALLATION_TOKEN'
-d '{
"title": "[A-1234] IntegrityError in core/models.py",
"body": "duplicate key violates unique constraint user_email_uniq\nDETAIL: Key (email)=(hubot@github.com) already exists..."
}'
</code></pre>
</li>
<li><p>You'll see the new content attachment appear under the link in a pull request or issue comment on GitHub:</p></li>
</ol>
<p><img src="https://user-images.githubusercontent.com/7718702/49371827-a4aa2c80-f6f0…
|
Issue still present but closed. |
This is an experiment with using lunr.js to power search. It works pretty well, but it's hard to tell this early on. I might just let this sit until we get a design and more content built out.
For inspiration, I really like Kickstarter's search.
TODO:
Design