Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add documentation for 'orgs init' #75

Merged
merged 1 commit into from
Jun 21, 2019
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
4 changes: 3 additions & 1 deletion CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,9 @@ Initial release. It includes a `docker-compose.yml` file to deploy source{d} CE

The `sourced` binary is a wrapper for Docker Compose that downloads the `docker-compose.yml` file from this repository, and includes the following sub commands:

- `init`: Install and initialize containers
- `init`: Install and initialize containers to analyze local repositories
- `orgs`: Manage services to analyze code from GitHub organizations
- `init`: Install and initialize containers to analyze GitHub organizations
- `status`: Shows status of the components
- `stop`: Stop running containers
- `start`: Start stopped containers
Expand Down
55 changes: 44 additions & 11 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,7 @@
- [Install source{d} Community Edition](#install-source-d-community-edition)
- [Usage](#usage)
- [Defaults](#defaults)
- [Initialization](#initialization)
- [Commands](#commands)
- [Working With Multiple Data Sets](#working-with-multiple-data-sets)
- [Docker Compose](#docker-compose)
Expand Down Expand Up @@ -68,9 +69,33 @@ You may also choose to manage the containers yourself with the `docker-compose.y
- Default login: `admin`
- Default password: `admin`

### Commands

#### Init
### Initialization

**source{d} CE** can be initialized from 2 different data sources: local Git repositories, or GitHub organizations.

Please note that you have to choose one data source to initialize **source{d} CE**, but you can have more than one isolated environment, and they can have different sources. See the [Working With Multiple Data Sets](#working-with-multiple-data-sets) section below for more details.

#### From GitHub Organizations

When using GitHub organizations to populate the **source{d} CE** database you only need to provide a list of organization names, and a [GitHub personal access token](https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/). The token should have the following scopes enabled:

- [x] `repo` Full control of private repositories
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually user can use token without any permissions than only open-source data will be downloaded. It's how I use srcd-ce. Not sure if we should mention it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually, maybe we should if we use src-d,bblfsh as example. There is no need for any permissions because external users aren't part of src-d or bblfsh orgs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 but even if it's technically possible, I'm not sure we want to document it.
I mean the hassle for the user that needs to create a token it's the same, we are not documenting a more convenient way. If we document private vs public, we may end up causing confusion,. Someone might use a token without access to private repos, and next week complain that the dashboards does not reflect those repos...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking a bit more about this:
This is intended to be friendly to anyone, not just developers. If I log into GitHub with my account, and I see private and public repos in some organizations, and public repos only on others. When I tell sourced to download repos from X,Y organization using authentication created from my account, my reference is what I see in GitHub. The less surprising result is to have the same repos, public and private.

If we want to provide a way to skip private repos, I think it should not be done tweaking the permissions of the GH token. It could be a setting from the CLI, or a filter in the dashboards.
But if we give here 2 options, and a user chooses permissions for public repos because they will maybe test over src-d, when they use the same token 2 weeks from now, they will forget about this detail, and they will not have visibility over why sourced is not showing private repositories.

If we could choose without authentication and with authentication, that would be great. But if we ask to go over the process to create the token, let's just go with one official way to do it, that we know will work as is expected by most people.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm going to merge, please feel free to open a new issue to continue this discussion if you still think it's better to change it.
It's a minor detail easy to change later.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I'm okay to discuss it later. I paid attention to it because I'm usually very careful with giving permissions to anything. If it's possible to avoid asking for extra permissions I always would prefer to do it.

- [ ] `admin:org` Full control of orgs and teams, read and write org projects
- [ ] `write:org` Read and write org and team membership, read and write org projects
- [x] `read:org` Read org and team membership, read org projects

Use this command to initialize:

```shell
sourced orgs init --token <token> src-d,bblfsh
```

It will automatically open the web UI. Use login: `admin` and password `admin` to access it.

If the UI wasn't opened automatically, use `sourced web` or visit http://localhost:8088.

#### From Local Repositories

```
sourced init /path/to/repositories
Expand All @@ -84,6 +109,8 @@ It will automatically open the web UI. Use login: `admin` and password `admin` t

If the UI wasn't opened automatically, use `sourced web` or visit http://localhost:8088.

### Commands

#### Start

```
Expand Down Expand Up @@ -182,29 +209,35 @@ Set the active docker compose file.

### Working With Multiple Data Sets

You can deploy more than one **source{d} CE** instance with different sets of repositories to analyze.
You can deploy more than one **source{d} CE** instance with different sets of organizations, or repositories, to analyze.

For example you may have initially started **source{d} CE** with the repositories in `~/repos`, with the command:
For example you may have initially started **source{d} CE** with the repositories in the `src-d` organization, with the command:
```
sourced init ~/repos
sourced orgs init --token <token> src-d
```

After a while you may want to analyze the data on another set of repositories. You can run `init` again with a different path:
After a while you may want to analyze the data on another set of repositories. You can run `init` again with a different organization:
```
sourced init ~/go/src/github.com/src-d
sourced orgs init --token <token> bblfsh
```

This command will stop any of the currently running containers, create an isolated environment for the new repositories path, and create a new, clean deployment.
This command will stop any of the currently running containers, create an isolated environment for the new data, and create a new, clean deployment.

Please note that each path will have an isolated deployment. This means that for example any chart or dashboard created for the deployment using `~/repos` will not be available to the new deployment for `~/go/src/github.com/src-d`.
Please note that each path will have an isolated deployment. This means that for example any chart or dashboard created for the deployment for `src-d` will not be available to the new deployment for `bblfsh`.

Each isolated environment is persistent (unless you run `prune`). Which means that if you decide to re-deploy **source{d} CE** using the original set of repositories:
Each isolated environment is persistent (unless you run `prune`). Which means that if you decide to re-deploy **source{d} CE** using the original organization:
```
sourced init ~/repos
sourced orgs init --token <token> src-d
```

You will get back to the previous state, and things like charts and dashboards will be restored.

These isolated environments also allow you to deploy **source{d} CE** using a local set of Git repositories. For example, if we wanted a third deployment to analyze repositories already existing in the `~/repos` directory, we just need to run `init` again:

```
sourced init ~/repos
```

If you are familiar with Docker Compose and you want more control over the underlying resources, you can explore the contents of your `~/.sourced` directory. There you will find a `docker-compose.yml` and `.env` files for each set of repositories used by `sourced init`.

## Docker Compose
Expand Down
2 changes: 1 addition & 1 deletion cmd/sourced/cmd/init.go
Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,7 @@ import (
)

type initCmd struct {
Command `name:"init" short-description:"Install and initialize containers" long-description:"Install, initialize, and start all the required docker containers, networks, volumes, and images.\n\nThe repos directory argument must point to a directory containing git repositories.\nIf it's not provided, the current working directory will be used."`
Command `name:"init" short-description:"Install and initialize containers to analyze local repositories" long-description:"Install, initialize, and start all the required docker containers, networks, volumes, and images.\n\nThe repos directory argument must point to a directory containing git repositories.\nIf it's not provided, the current working directory will be used."`

Args struct {
Reposdir string `positional-arg-name:"workdir"`
Expand Down
6 changes: 3 additions & 3 deletions cmd/sourced/cmd/orgs.go
Original file line number Diff line number Diff line change
Expand Up @@ -13,13 +13,13 @@ import (
)

type orgsCmd struct {
cli.PlainCommand `name:"orgs" short-description:"Manages services to analyze code from GitHub organizations"`
cli.PlainCommand `name:"orgs" short-description:"Manage services to analyze code from GitHub organizations" long-description:"Manage services to analyze code from GitHub organizations"`
}

type orgsInitCmd struct {
Command `name:"init" short-description:"Install and initialize containers to analyze github organizations" long-description:"Install, initialize, and start all the required docker containers, networks, volumes, and images.\n\nThe orgs argument must a list of the organizations to be analyzed."`
Command `name:"init" short-description:"Install and initialize containers to analyze GitHub organizations" long-description:"Install, initialize, and start all the required docker containers, networks, volumes, and images.\n\nThe orgs argument must a comma-separated list of GitHub organization names to be analyzed."`

Token string `short:"t" long:"token" description:"Github token for the passed organizations. It should be granted with 'repo' and 'read:org' scopes." required:"true"`
Token string `short:"t" long:"token" env:"SOURCED_GITHUB_TOKEN" description:"Github token for the passed organizations. It should be granted with 'repo' and 'read:org' scopes." required:"true"`
Args struct {
Orgs []string `required:"yes"`
} `positional-args:"yes" required:"1"`
Expand Down