|
| 1 | + |
| 2 | +* [github2mr](#github2mr) |
| 3 | + * [Brief mr Example](#brief-mr-example) |
| 4 | +* [Installation](#installation) |
| 5 | +* [Configuration / Usage](#configuration--usage) |
| 6 | + * [Other Git Hosts](#other-git-hosts) |
| 7 | +* [Github Setup](#github-setup) |
| 8 | + |
| 9 | + |
| 10 | + |
| 11 | + |
| 12 | +# github2mr |
| 13 | + |
| 14 | +Many [Github](https://github.com/) users have a large number of repositories upon which they work. This application allows you to dump all your repository details into a configuration file for [myrepos](https://myrepos.branchable.com/). |
| 15 | + |
| 16 | +The myrepos package, containing a binary named `mr`, is a _wonderful_ tool that lets you apply operations to multiple repositories at once given a suitable configuration. |
| 17 | + |
| 18 | +The end result of using `mr` and `github2mr` is that you should be able to clone all your remote github repositories, and update them easily with only a couple of commands which is great for when you work/develop/live on multiple machines. |
| 19 | + |
| 20 | + |
| 21 | +## Brief `mr` Example |
| 22 | + |
| 23 | +Let us pretend I'm moving to a new machine; first of all I export the list of all my remote repositories to a configuration file using _this_ tool: |
| 24 | + |
| 25 | + github2mr > ~/Repos/.mrconfig.github |
| 26 | + |
| 27 | +* **NOTE**: The first time you create a new configuration file you will need to mark it as being trusted, because it is possible for configuration files to contain arbitrary shell-commands. |
| 28 | + * Mark the configuration file as trusted by adding it's name to `~/.mrtrust`: |
| 29 | + * `echo ~/Repos/.mrconfig.github >> ~/.mrtrust` |
| 30 | + |
| 31 | +Now that we've populated a configuration-file we can tell `mr` to checkout each of those repositories: |
| 32 | + |
| 33 | + mr --jobs 8 --config ~/Repos/.mrconfig.github |
| 34 | + |
| 35 | +Later in the week I can update all the repositories which have been cloned, pulling in any remote changes that have been made from other systems: |
| 36 | + |
| 37 | + mr --jobs 8 --config ~/Repos/.mrconfig.github update |
| 38 | + |
| 39 | +**NOTE**: If you prefer you can just use `update` all the time, `mr` will checkout a repository if it is missing as part of the `update` process. I'm using distinct flags here for clarity. Please read the `mr`-manpage to look at the commands it understands. |
| 40 | + |
| 41 | + |
| 42 | +# Installation |
| 43 | + |
| 44 | +You should be able to install this application using the standard golang approach: |
| 45 | + |
| 46 | + $ go get github.com/skx/github2mr |
| 47 | + |
| 48 | +If you prefer you can [download the latest binary](http://github.com/skx/github2mr/releases) release, for various systems. |
| 49 | + |
| 50 | + |
| 51 | + |
| 52 | + |
| 53 | +# Configuration / Usage |
| 54 | + |
| 55 | +Once installed you'll need to configure your github token, which you can generate from [withing your github settings](https://github.com/settings/tokens). |
| 56 | + |
| 57 | +you can either pass the token as an argument to the tool (via `github2mr -token=xxxxx`), or store it in the environment in the variable GITHUB_TOKEN: |
| 58 | + |
| 59 | + $ export GITHUB_TOKEN=xxxxx |
| 60 | + $ github2mr [options] |
| 61 | + |
| 62 | +You can run `github2mr -help` to see available options, but in brief: |
| 63 | + |
| 64 | +* You can choose a default prefix to clone your repositories to. |
| 65 | + * By default all repositories will be located at `~/Repos/${git_host}`. |
| 66 | +* You can exclude all-organizational repositories. |
| 67 | + * Or the reverse, ignoring all personal-repositories. |
| 68 | +* You can exclude repositories by name. |
| 69 | +* You can default to cloning repositories via HTTP, instead of SSH. |
| 70 | + |
| 71 | + |
| 72 | +## Other Git Hosts |
| 73 | + |
| 74 | +This tool can be configured to point at other systems which use the same |
| 75 | +API as the public-facing Github site. |
| 76 | + |
| 77 | +To use it against a self-hosted Github Enterprise installation, for example, |
| 78 | +simply specify the URL: |
| 79 | + |
| 80 | + $ export GITHUB_TOKEN=xxxxx |
| 81 | + $ github2mr -api=https://git.example.com/ [options] |
| 82 | + |
| 83 | +It has also been tested against an installation of [gitbucket](https://github.com/gitbucket/gitbucket) which can be configured a similar way - however in this case you'll find that you receive an error "401 bad credentials" unless you add the `-auth-header-token` flag: |
| 84 | + |
| 85 | + $ export GITHUB_TOKEN=xxxxx |
| 86 | + $ github2mr -api=https://git.example.com/ -auth-header-token |
| 87 | + |
| 88 | +This seems to be related to the OAUTH header the library I'm using sends, by default it will send a HTTP request looking like this: |
| 89 | + |
| 90 | +``` |
| 91 | +GET /api/v3/users/skx/repos HTTP/1.1 |
| 92 | +Host: localhost:9999 |
| 93 | +User-Agent: go-github |
| 94 | +Accept: application/vnd.github.mercy-preview+json |
| 95 | +Authorization: Bearer SECRET-TOKEN |
| 96 | +Accept-Encoding: gzip |
| 97 | +``` |
| 98 | + |
| 99 | +Notice that the value of the `Authorization`-header begins with `Bearer`? Gitbucket prefers to see `Authorization: token SECRET-VALUE-HERE`. |
| 100 | + |
| 101 | + |
| 102 | + |
| 103 | + |
| 104 | +# Github Setup |
| 105 | + |
| 106 | +This repository is configured to run tests upon every commit, and when |
| 107 | +pull-requests are created/updated. The testing is carried out via |
| 108 | +[.github/run-tests.sh](.github/run-tests.sh) which is used by the |
| 109 | +[github-action-tester](https://github.com/skx/github-action-tester) action. |
| 110 | + |
| 111 | +Releases are automated in a similar fashion via [.github/build](.github/build), |
| 112 | +and the [github-action-publish-binaries](https://github.com/skx/github-action-publish-binaries) action. |
| 113 | + |
| 114 | + |
| 115 | +Steve |
| 116 | +-- |
0 commit comments