GitHub has changed how organization administrators can control access to their repositories for third-party applications, such as Semaphore. As explained in their blog post, third-party restrictions allow you to gain a more fine grained control over your organization’s repositories and the data on GitHub.
As of February 24, 2015 this is reflecting on how Semaphore interacts for all GitHub repositories owned by organizations which have enabled third-party application restrictions. The technical details are on GitHub’s developer blog. This post summarizes the actions we are taking on Semaphore to adapt to GitHub’s new policies as well as actions you will need to take if you are an owner of an organization on GitHub.
Actions we are taking
Enabling third-party application restrictions on GitHub will invalidate all SSH keys created before February 2014, which are part of your organization. For this reason, we will regenerate deploy keys which fall into that timespan. If your project is affected, you’ll receive an email from GitHub stating that a new deploy key has been added to your repository.
Actions you need to take
If you don’t enable third-party application restriction on GitHub, there are no actions required on your side.
Restricting third-party applications for your organization has some repercussions. If you plan on using these restrictions, please consult this page on GitHub for all the details.
One notable change is that GitHub will blacklist all current SSH keys and new keys have to be approved. You’ll notice this when you try to access the organization’s repository by either a push, pull or clone actions. When this happens, an error message will guide you through the process of verifying your SSH key. This is affecting both deploy and user keys.
If you notice any anomalies, please contact us as soon as possible through a support ticket or on live chat so we can solve the issue in a timely manner.
Happy building!