i am interested in building a github app. reading through github Setting up your development environment to create a GitHub App documentation it explains that a github app is based on a http server which will handle webhooks.
yet, on every github app i installed, the app\installation did not require anything that involves hosting and/or creation of http server in order to deploy the app to my github accout.
for such github apps, which are installed directly through the github marketplace (you can take probot stale and rennovate as examples for such apps)
where do these application run? (e.g.; does github deploys the app on a dedicate (virtual) server?).
what are the resources limitations for such apps (amount of memory, cpu, etc.?)
how can the github app logs be accessed by the github account owner who installed such app?
links for reference and an answer will be great.
GitHub App is just another app that you create. GitHub apps are treated as first-class citizens when it comes to integrating with GitHub. One can use Nodejs , Ruby, etc to build the App. Once the app is ready it can be hosted on a Server just like any other server hosted apps. You register your app on GitHub by providing relevant details.
So, coming to your questions.
The Apps can run on any hosting service of your choice. It can be a Windows Server, Heroku, etc.
I believe it is only limited by the resource of your server or the hosting service provider that you chose. However you might be ineterset in erading more about the Rate Limit More on Rate limits here.
GitHub app logs are something which only the developer will be able to see. To the end user ,i.e. the repo owner who installed the GitHUb app on his repos, all that will be available are the checks , statuses and any other details that the developer of app decided to display.
A very handy guide on Deployment and other details : Probot Documentation. This documentation is great if you are planning to use the probot framework for developing your github apps, but most of the instructions still stand true in case you decide to pick up a different tech stack.
The most important thing to realise about a (so-called?) Github App is that the App itself does not run anywhere - or at least that is what I would argue. Basically Github Apps are two linked mechanisms, both a bit of infrastructure. The first of these mechanisms is access control, essentially replacing use of user PATs - you can give relatively fine grained access to repos that the App is installed in, rather than just giving access to all repos the user can access. The second mechanism is that of webhooks - generating events as requested.
What Github Apps do not directly provide is the bit between this - handling the webhooks and generating API calls using the App for access. Basically you are on your own and need to do it yourself. The plus, #asif-kamran-malick mentioned, is that you have freedom to implement it how you see fit.
One alternative possibility is that the App itself, rather than setting to handle ongoing Webhooks, runs on installation and looks to add Actions into the repo. Never done it, but some of the github examples seem to work this way. Of course, Actions are run within Github environments and are potentially subject to resource limits. Apart from this though, Actions are a completely separate "beast" and should not be confused.
Related
We'd like for the PR approval for an application created in Google App Engine to return the project version URL to display in GitHub (so this can be passed on to the test team as a standalone entity). Not sure if this is actually possible. Has anyone had any luck doing this before?
So far, I have not been able to find any documentation for this, although plenty helping to connect GitHub processes to GCP.
We have been tripped up twice recently as our development output has increased.
We have a; backend services, an Admin SPA site and a number of frontend applications including native apps. All in different repos
We also have a fully automated CI/CD pipelines for everything that works fantastically.
What has happened recently is the public applications have gotten ahead of the Admin SPA which is making the team look bad.
Has anyone seen a solution that requires minimum input for developers - the more I can rely on automation the better.
The goal is to keep feature deployments in concert
Tanks
So the plan is to go down versioning with Semantic versioning and a route on admin that returns a json response with the version number.
The build and deploy for admin takes in the version and returns it.
The deploy for reliant apps has a script that queries admin before starting.
There is still a bit of manual work for the developers but it is manageable.
Thanks #Bruno
What is the difference between a GitHub App and the REST API for GitHub? Why would you need a GitHub App if you can just use the REST API, without setting any environment up?
The REST API should just be a collection of endpoints that accept a POST along with access tokens. But the GitHub App requires cloning an entire repo written in Ruby, that has nothing to do with my app.
I am not looking for users to integrate with my repo, I want them to be able to connect their own repo to the application.
But the GitHub App requires cloning an entire repo written in Ruby, that has nothing to do with my app.
I don't believe this is true.
GitHub Apps make the process of integrating 3rd party tools into your GitHub repositories smoother.
GitHub Apps are installed by organizations and granted access to specific repositories via GitHub. For example, CodeClimate is a tool which performs checks on pull requests. Rather than granting them OAuth access to my repositories, I can install the CodeClimate GitHub App on my organization and configure which repositories they have access to. I can see all the apps installed and what their permissions are.
Note that "installing" a GitHub App does not install any code. "Installing" gives the app permissions for the service to access your organization and repos. A GitHub App is a wrapper around an existing service.
If you want users to connect their repos to your application, consider a GitHub App.
This is covered in About apps.
An OAuth App acts as a GitHub user, whereas a GitHub App uses its own identity when installed on an organization or on repositories within an organization.
GitHub Apps are the officially recommended way to integrate with GitHub because they offer much more granular permissions to access data, but GitHub supports both OAuth Apps and GitHub Apps.
GitHub Apps are first-class actors within GitHub. A GitHub App acts on its own behalf, taking actions via the API directly using its own identity, which means you don't need to maintain a bot or service account as a separate user.
GitHub Apps can be installed directly on organizations and user accounts and granted access to specific repositories. They come with built-in webhooks and narrow, specific permissions. When you set up your GitHub App, you can select the repositories you want it to access. For example, you can set up an app called MyGitHub that writes issues in the octocat repository and only the octocat repository. To install a GitHub App, you must be an organization owner or have admin permissions in a repository.
GitHub Apps are applications that need to be hosted somewhere. For step-by-step instructions that cover servers and hosting, see "Building Your First GitHub App."
Differences between GitHub Apps and OAuth Apps has a complete breakdown.
Is it possible to tell if a release which is published on a GitHub repo was made by someone who logged in with 2FA?
The reason for asking is that we have a tool that integrates GitHub releases (from repos made by other people, ie not part of our GitHub organisation) into an application, and is capable of auto-updating to the latest release.
Although it's user friendly to auto-update, if someone were to steal the credentials of that GitHub user (because they do not use 2FA) then the auto-update could end up installing maliciously crafted code. This scenario has happened to npmjs.
It would be useful to be able to identify that the release was made by someone who does not use 2FA and warn that the release might be "unsafe".
Our application is part of Qooxdoo http://www.qooxdoo.org, which is an open source Javascript development framework.
For educational purpose, I am writing a server instance in GCE(google compute engine) to serve a few web apps mostly (to be) written in Dart and Polymer.
My workflow is, when my students log-in the server above, they will automatically fork those web apps into their own registries in their own server instances for further development.
My issues are,
How to serve web applications(they are git registries as well) in GCE like Github Pages?
Is it possible to manipulate Github Pages to serve web apps mostly using Dart and Polymer packages?
Thanks in advance.
I found out answers to my questions.
1. How to serve web applications(they are git registries as well) in GCE like Github Pages?
Use CI(continuous integration).
2. Is it possible to manipulate Github Pages to serve web apps mostly using Dart and Polymer packages?
No.
My question is summarized to the sentence that 'Is it possible to assign IP addresses on index.html files in git repositories?'. If possible, there is no need of CI processes at all as 'A repository itself is A web server or directory running the code'.
CI is more or less documented in Github Pages and Gitlab CI etc. Though details are different, they commonly use hooks(or webhooks) to notify something from repo to another server(s), which are application servers.
In my opinion, GIT is NOT designed and has NOT evolved for web applications, but for 'REAL' applications needing compile/build processes. So, there is no mechanism to run a repo as a web server. So, the only solution is to hack the source code of Gitlab etc. to make a better Github Pages(it supports only static pages, and NOT JS and other libraries etc.).
Disclouse: based on the advice of Günter Zöchbauer