There is an unstable gitlab server and I am not sure that it will be able to work in the future. Therefore, I want to make a backup copy of all the repositories (projects) that are there.
Cloning the source code will be enough, but it will be great if there is a way to save issues as well. Are there any ways to do this?
It depends on what kind of access you have, but if you don't have administrator access to do a full backup, then the best thing to do is to use a couple of API endpoints to get the information you need and go from there.
Use the Projects API to get a list of all projects accessible to you.
Note the pagination limits.
What you store depends on how you want to get the information.
Store at least the ID number of each.
Filter by membership if you only want the ones you're a member of.
Filter by min_access_level = maintainer (or higher) if you want to export whole projects.
Use the Project export API to trigger a project export for each project you're a member of, and you're a maintainer (or higher).
For all other projects where you have a lower role, or where it's public, you could still use git clone for the repositories by storing the ssh_url_to_repo or http_url_to_repo from the Projects API and running through each.
For all other parts of a project, you could store the JSON version to recreate them later if you want to go through the hassle. For example, for issues, use the Issues API.
I have been trying to create a simple Probot app that amongst other things will merge PRs on certain criteria being met. (I am aware prebuilt solutions are available, however not only do they not quite fit my needs, I won't learn anything).
Using context.github.pulls.merge(context.issue()) returns: ERROR probot: Resource not accessible by integration
I have tried replacing context.issue() with the object the docs suggest its looking for.
Googling although difficult to find similar issues, suggest its a permission issue, I have double checked the permissions and at one stage given the app every permission.
Things worth noting:
There are no github actions setup on this repo
The repo belongs to a testing org, the bot app has access to all repos in the org
The repo was initially private, but have also tested in public
Any nudge in the right direction will be greatly appreciated.
Thanks
I see it has been quite a while since you posted this question.
You should not be using context.github.pulls.merge(context.issue()) in the first place. This will never work given the signature of the actual merge method(). You said you have tried following the doc's suggestion.
Is this the doc you are referring to?
The doc clearly suggests to provide owner, repo and pull_number to context.github.pulls.merge().
Did you try that? Please dod share your findings.
I'd like to get a list of users who have starred my public repo and a number of fields related to them such as whether or not they have cloned it. Is this possible with the Github API?
The endpoint for stargazers is:
https://api.github.com/repos/:owner/:repo/stargazers
for eg, if you want to get users who starred the repo https://github.com/suhailvs/django-schools/ you can use:
https://api.github.com/repos/suhailvs/django-schools/stargazers
The endpoint for stargazers (users who have starred a repo) is documented here in the documentation. You can follow with additional requests on those users.
Checking whether people have cloned a repo is impossible (you don't even need to be logged in to clone a git / GH repo). You can, however, list the forks of a repo.
Github webhook services are fairly detailed and you can really get a lot of information from them but gleaning if someone cloned your repo is a bridge too far. As far as I'm aware, there's no way to track that (you can track new forks). I'd recommend using a webhook to track new repo watches to accomplish at least some of what you're looking for.
Axibase has a tool which leverages Github webhooks, and notifies you via email or instant message (through the messenger of your choice) when someone stars your repository.
The underlying process is here:
It's a quick setup, the whole process takes less then 10 minutes. Basically you need to create a plaintext file with your email / messenger credentials on your local machine, launch an ATSD sandbox from the terminal, and paste the webhook generated at runtime into the appropriate field on Github. The full process is here.
Disclaimer: I work for Axibase
I am trying to find a way to search multiple project's code in gitlab CE.
Has anyone encountered this before, or have a recommended approach?
(I realize that if this is even possible, then I would likely need to create a script that mimics the current call from the GUI multiple times and combine the results. )
Recently came into a similar need. My particular use case is a self-hosted instance of GitLab CE. Seems like it's possible to use GitLab's API where the scope is limited to snippet, then loop through your groups and projects.
Example code:
https:// (instance_server) /search?utf8=%E2%9C%93&snippets=&scope=&search= (key words) &group_id=22&project_id=81
Other links:
GitLab's paid version.
https://docs.gitlab.com/ee/user/search/advanced_search_syntax.html#syntax-search-filters
Mention of original request (closed)
https://gitlab.com/gitlab-org/gitlab-ce/issues/14597
https://forum.gitlab.com/t/search-code-across-all-projects/2263 (SourceGraph)
You can create a Group, migrate or move all of the projects you want to search to that group, and then search just that group.
So I'm using Visual Studio 2012, and whenever I create a new project I always leave out the "Add to source control" option, mainly because I don't what it is, what it's purpose is, or if it would be beneficial to me to use it.
I'm developing a rather large library on my own. I plan on making it open source. Is this what source control is for? Reading up online did not help me unfortunately, I'm still desperately confused. Is source control the same as version control too, by the way?
Some clarification would be greatly appreciated.
Thanks!
Alex
Source control (otherwise known as revision control: http://en.wikipedia.org/wiki/Revision_control) is a way in which you can store and manage changes and revisions to your code-base.
Google: SVN, Git, Mercurial and Google Code, GitHub, Bitbucket.
I personally never start a propject (personal or otherwise without it). Also, I like BitBucket (www.Bitbucket.com) for managing my projects. It's free for a single user and they support Git and Mercurial.
Quite simply, source control is a repository where your source code is stored. It's purpose is to provide a storage spot that is separate to the copy that you are currently working with, so you can make changes locally and then submit them back to your source control repository.
Think of it as being like a library - you can get code out, you can return (modified) code to it. It also gets more complex than that - you can use source control to handle multiple versions of the same source, and to merge changes from one copy to another. Additionally most (all) source control systems should provide a mechanism for tracing changes to code (i.e. audit tracking), and a means to "roll back" or revert to a previous version.
There are a variety of source control systems, some of which you install locally and some which you install centrally and access remotely. In all cases the underlying philosophies are mostly the same, although there are some differences around terminology and implementation of features. Source control is considered to be a system that is separate to your editor, your editor then provides a means to specify which source control provider to use and the location of the source control repository.
I have found this
Git Source Control Provider is a plug-in that integrates git with
Visual Studio
According to this, seems like source control = version control
You were asked this when starting a project because it's much easier to setup before you have many messy pieces. Github is a form of version control. An organized place for code to grow.
Version control really shines if you're collaboratively working on a project with many different pieces to it. Source or version control is the process of taking the many different parts that are being worked on simultaneously and bringing them together as a final project.
If you're working on your own it still may be beneficial to practice with, as still holds some value in allowing a process of documentation, and modular pieces being brought together for a final project.
This wonderful post explains many of the benefits of using version control for your pet projects.
Well, there are a number of good reasons:
1. It’s good to be in the habit. Sure, you may be working alone. But in
the future you may not be. Or your “weekend hobby project” might turn
into a popular project with many developers. If anything like that
happens, being in the habit of using source code control will stand
you in good stead.
2. It protects your code. Since your code is stored
in on a server apart from your development machine, you have a backup.
And then, you can even backup the code on the server. Sure, you can
zip it all up any time you want, but you don’t get all the other
benefits I’m listing here.
3. It can save your butt. Sometimes, you
might accidently delete something. You might make mistakes and change
code that you didn’t want changed. You might start off on some crazy
idea when you are feeling a bit saucy, and then regret it. Source
control can save you from all of these by making it a piece of cake to
revert to any previous state. It’s like a really powerful “undo”
feature.
"Source control" refers to the concept of storing all files that make up the source of an application in an (usually online) repository - where one can manage with fine detail exactly what has changed in the source code between versions, manage issues, involve other people with the project, and generally provide a platform to collaboratively manage a project.
The term is usually synonymous with version control - although you can have a repository and not explicitly name versions. Version control in particular just refers to labeling major versions of your project with a hierarchical numbering scheme (1.2.4 etc.)
There are several different tools that implement different kinds of source control. For example, Git is a source control tool that sets lets you manage a project. Github is a web-site that repositories managed with Git are usually stored on. Mercurial is yet another source control tool.
Typically, source control can be complicated to understand, and usually requires significant time studying tutorials. A lot of concepts are unfamiliar to solo programmers who have only worked on small projects. Changes to source code are managed through commits, and different branches of the project can be worked on by multiple people. Changes from separate branches can be merged, and the project can be forked by another user entirely (at least for Git).
Making your library open source is a good idea, and it's not too hard to give it a home on github. I would look into some resources to find out how to set it up.
Wikipedia says:
Revision control, also known as version control and source control
(and an aspect of software configuration management), is the
management of changes to documents, computer programs, large web
sites, and other collections of information. Changes are usually
identified by a number or letter code, termed the "revision number",
"revision level", or simply "revision". For example, an initial set of
files is "revision 1". When the first change is made, the resulting
set is "revision 2", and so on. Each revision is associated with a
timestamp and the person making the change. Revisions can be compared,
restored, and with some types of files, merged.
In simpler terms, source control allows multiple people to work on the same project without everyone clobbering everyone else's changes. Changes to the same file are merged together, and conflicts can be resolved.
It also allows you to keep version history. You can roll back a file to the way it existed at any point in time, as well as maintain different branches of the program; a way to organize groups of changes.
As Si puts it, source (or version) control will save your life 20 times over.
Source control keeps a detailed history of your code. This enables you and any collaborators to:
Review the history of any code
See changes between two versions
Revert any code you just goofed up
Prevent you from losing any code
Discover which changes caused bugs / crashes
Blame whoever messes up your code
Keep an up-to-date backup of all of your code
Even if you're not working collaboratively, source control is so useful when you accidentally delete your code. I speak from experience.
I would recommend using Git or Mercurial, as they allow branching and offer a more isolated workspace for collaborators to experiment without fear of harming any code.
For online collaboration, Github and Bitbucket are great and integrate well with Git and Mercurial, respectively. They also allow you to track collaborators' changes, choose and merge changes into a central repository, and keep a detailed list of issues.