I'm a contractor developing an app for a client and the code and exes are stored in a private github repository. They plan to sell the app through a WordPress-based store. I assumed or thought I read somewhere that files could be hosted on GitHub and in my tests it seemed to work – except it only worked because I was logged in to GitHub, with access to the private repo.
Is there some setting or "feature" on GitHub which will allow us to link to an exe (or zip) from another site or from a link in a "purchase confirmation" type email?
I've seen Hosting executable on github but it is quite old now and not really about private repos.
GitHub does allow you to host release assets as part of a release based on a tag, but these assets are controlled with the permissions of the repository. If the repository is public, then the release assets will also be public; if it is private, then they will also be private, with the same permissions of the repository.
If what you're trying to do is use GitHub with a custom access control system to allow only people who have purchased the software to download it, then that's not possible, and you'll need to set up your own server with the binaries. GitHub provides release assets so that folks can distribute binaries and other compiled stuff without needing to check them in, but it's not designed to be your CDN or web store.
Related
I just signed up for GitLab, after learning about this cool feature where you can import your GitHub repositories and keep the two in sync. The import feature seems simple enough, but I paused when I got to the step where I authorize GitLab to my GitHub account. Why does it need so many permissions? Some make sense to me, others not so much. Specifically:
Personal user data
Full access
This application will be able to read and write all user data. This
includes the following:
Private email addresses
Private profile information
Followers
I understand why it needs to read and write to all public and private repository data. It's moving all that data to GitLab, and it needs to write to keep it in sync. What I don't understand is why it needs write permissions to my email and profile information?
I know that GitLab is a reputable company that didn't just pop up yesterday, but I am still wary when giving full access permissions to any service. If someone could help me understand, that would be appreciated.
You have two options when migrating a repository from GitHub to GitLab. You can migrate using only the url, in which case what you’ll have on GitLab is more similar to what you’d get if you simply added an additional remote in the repo - the full repo will be there, but everything specific to GitHub - the pull requests, comments, issues, etc, as well as all users tagged or participating - will be lost.
Alternatively, you can use the GitHub importer. This option fully migrates the GitHub repo to GitLab, setting up the GitLab equivalents of GitHub features (pull requests become merge requests, etc.). And part of this involves assigning users to each comment, mention, PR, etc.
From the gitlab docs:
When issues and pull requests are being imported, the importer attempts to find their GitHub authors and assignees in the database of the GitLab instance. Pull requests are called merge requests in GitLab.
For this association to succeed, each GitHub author and assignee in the repository must meet one of the following conditions prior to the import:
Have previously logged in to a GitLab account using the GitHub icon.
Have a GitHub account with a public-facing email address that matches their GitLab account’s email address.
GitLab content imports that use GitHub accounts require that the GitHub public-facing email address is populated. This means all comments and contributions are properly mapped to the same user in GitLab. GitHub Enterprise does not require this field to be populated so you may have to add it on existing accounts.
So yes, these are required if you want the full GitHub mirror or migration. If you just want the git repo contents, use the import from url tool, and the requirements will be much less extensive.
The project I'm working on currently deploys our private node packages via github packages. Our current workflow is for each developer to create and maintain their own personal access token, and then we use a central account's PAT for automation in AWS.
I was wondering if it's possible to authenticate with github packages without the use of Actions or PAT's?
As of 2022-07-30
No, it is not possible to use github packages without a personal access token (PAT):
It is not possible to upload without a PAT (which makes sense as it prevents random people to upload binaries to your package repo);
It is not possible to download without a PAT (not even publicly available packages can be used);
As early as 2019-10-20, people have requested github to remove PATs as a requirement for mainly downloading public packages.
The idea is that users of libraries should not need to have a github account to access a developer's package.
Sadly, the request for pat-less package downloads was not granted by Github to this day.
If you want a package registry without a hassle, it might be wise to look for other registries, such as MavenCentral or JitPack (not necessarily meant for node packages),
or host a service yourself.
I even had to link a cached webpage, as the original question has been removed from Github community along with a bunch of related questions.
Another question on github, stating pat-less access to packages is still on the roadmap for "fall 2021" is here.
I could not find what the current status of this feature is.
Edit: It is possible to download binaries without a PAT for public repositories using jitpack.io. Jitpack builds the given jar/aar on their servers.
You can add jitpack as a repository to your build system, and use the jitpack-specified URL to reference releases, branches, or specific commits.
Sadly, there is no way to refer to packages (yet).
However, this system allows your users to use your code without needing PATs nor a Github account.
I'd like to offer an alternative.
You may use a Gradle plugin of mine (magik, I was exactly in your shoes) to easier the consumption of artifacts from your Github Packages for Gradle clients.
It require you to save your read-only PAT on the repo itself, so that the users don't have to deal with any authentication (apart using the plugin above mentioned)
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.
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.
On GitHub sadly, a private repo is for premium users, and i uploaded a repo, but it has lot of login third party, and i want to make those login information private, and i have a MongoHQ connection, and want to make the database private, to deploy it on CloudControl.
How CloudControl and Heroku work, is that by taking the file AFTER the clone on disk or the clone is only 'temporary' file, and they take the one hosted on Github?
There is no need to have any credentials in the repository. It's actually highly discouraged to do so. The recommended way is to have your code read the credentials from the environment.
Refer to the Add-on credential section in the documentation for more details: https://www.cloudcontrol.com/dev-center/Platform%20Documentation#add-on-credentials