sourcegraph / src-cli

Sourcegraph CLI

Sourcegraph CLI

src is a command line interface to Sourcegraph:

• Search & get results in your terminal
• Search & get JSON for programmatic consumption
• Make GraphQL API requests with auth easily & get JSON back fast
• Execute batch changes
• Manage & administrate repositories, users, and more
• Easily convert src-CLI commands to equivalent curl commands, just add --get-curl!

Note: Using Sourcegraph 3.12 or earlier? See the older README.

Installation

Binary downloads are available on the releases tab, and through Sourcegraph.com. If the latest version does not work for you, consider using the version compatible with your Sourcegraph instance instead.

Installation: Mac OS

Latest version

curl -L https://sourcegraph.com/.api/src-cli/src_darwin_amd64 -o /usr/local/bin/src
chmod +x /usr/local/bin/src

or with Homebrew:

brew install sourcegraph/src-cli/src-cli

or with npm:

npm install -g @sourcegraph/src

Version compatible with your Sourcegraph instance

Replace sourcegraph.example.com with your Sourcegraph instance URL:

curl -L https://sourcegraph.example.com/.api/src-cli/src_darwin_amd64 -o /usr/local/bin/src
chmod +x /usr/local/bin/src

or, if you know the specific version to target, for example 3.43.2:

brew install sourcegraph/src-cli/[email protected]

or with npm/npx:

npx @sourcegraph/[email protected] version

Note: Versioned formulas are available on Homebrew for Sourcegraph versions 3.43.2 and later.

Installation: Linux

Latest version

curl -L https://sourcegraph.com/.api/src-cli/src_linux_amd64 -o /usr/local/bin/src
chmod +x /usr/local/bin/src

or with npm:

npm install -g @sourcegraph/src

Version compatible with your Sourcegraph instance

Replace sourcegraph.example.com with your Sourcegraph instance URL:

curl -L https://sourcegraph.example.com/.api/src-cli/src_linux_amd64 -o /usr/local/bin/src
chmod +x /usr/local/bin/src

or, with npm/npx, if you know the specific version to target, for example 3.43.2:

npx @sourcegraph/[email protected] version

Installation: Windows

See Sourcegraph CLI for Windows.

Installation: Docker

sourcegraph/src-cli is published to Docker Hub. You can use the latest tag or a specific version such as 3.43. To see all versions view sourcegraph/src-cli tags.

docker run --rm=true sourcegraph/src-cli:latest search 'hello world'

Log into your Sourcegraph instance

Run src login SOURCEGRAPH-URL to authenticate src to access your Sourcegraph instance with your user credentials.

Examples src login https://sourcegraph.example.com src login https://sourcegraph.com

src consults the following environment variables:

• SRC_ENDPOINT: the URL to your Sourcegraph instance (such as https://sourcegraph.example.com)
• SRC_ACCESS_TOKEN: your Sourcegraph access token (on your Sourcegraph instance, click your user menu in the top right, then select Settings > Access tokens to create one)

For convenience, you can add these environment variables persistently.

Configuration: Mac OS / Linux

Add the following to your terminal profile file, typically accessible at ~/.bash_profile (if using Bash) or ~/.zprofile (if using Zsh):

export SRC_ACCESS_TOKEN=my-token
export SRC_ENDPOINT=https://sourcegraph.example.com 

Replace my-token and https://sourcegraph.example.com with the appropriate values for your account and instance.

You can also inline them in a single command with:

SRC_ENDPOINT=https://sourcegraph.example.com SRC_ACCESS_TOKEN=my-token src search 'foo'

Configuration: Windows

Type the following on your PowerShell terminal:

$env:SRC_ENDPOINT = 'https://sourcegraph.example.com'
$env:SRC_ACCESS_TOKEN = 'my-token'

Replace my-token and https://sourcegraph.example.com with the appropriate values for your account and instance.

You can also manually add them via the System Properties windows. Check this post for details.

Is your Sourcegraph instance behind a custom auth proxy? See auth proxy configuration docs.

Usage

src provides different subcommands to interact with different parts of Sourcegraph:

• src login - authenticate to a Sourcegraph instance with your user credentials
• src search - perform searches and get results in your terminal or as JSON
• src api - run Sourcegraph GraphQL API requests
• src batch - execute and manage batch changes
• src repos - manage repositories
• src users - manage users
• src orgs - manages organization
• src config - manage global, org, and user settings
• src extsvc - manage external services (repository configuration)
• src extensions - manage extensions
• src code-intel - manages Code Intelligence data (deprecated alias: src lsif)
• src serve-git - serves your local git repositories over HTTP for Sourcegraph to pull
• src version - check version and guaranteed-compatible version for your Sourcegraph instance

Run src -h and src <subcommand> -h for more detailed usage information. You can also read the usage docs for the latest version of src-cli online.

Optional: Renaming src

If you have a naming conflict with the src command, such as a Bash alias, you can rename the static binary. For example, on Linux / Mac OS:

mv /usr/local/bin/src /usr/local/bin/src-cli

You can then invoke it via src-cli.

Telemetry

src includes the operating system and architecture in the User-Agent header sent to Sourcegraph. For example, running src version 3.21.10 on an x86-64 Linux host will result in this header:

src-cli/3.21.10 linux amd64

To disable this and only send the version, you can set -user-agent-telemetry=false for a single command, or set the SRC_DISABLE_USER_AGENT_TELEMETRY environment variable to any non-blank string.

As with other Sourcegraph telemetry, any collected data is only sent to Sourcegraph.com in aggregate form.

Development

Some useful notes on developing src can be found in DEVELOPMENT.md.

src-cli's Issues

SRC_ENDPOINT not respected?

I set SRC_ENDPOINT to my local instance. Running src campaigns list did not return anything, despite campaigns existing in the UI.
Then I also set SRC_ACCESS_TOKEN, and got

error: 401 Unauthorized

Invalid access token.

The fact that I just created this token yet it is invalid tells me that SRC_ENDPOINT is not respected.

Passing -endpoint explicitly works.

Make src-config file hidden and chmod it

You should ensure that the file is considered "hidden" as a good practice. $HOME/.src-config.json as well as perform a chmod 600 on it. Not the craziest thing in the world but it's weird having it found on my desktop.

a8n: Node package upgrade campaign not failing when yarn-error.log file produced

When running a campaign to upgrade RxJS, 4 repositories had yarn-error.log files added as part of their diff. You can see the results of this draft campaign at https://demo.sgdev.org/campaigns/Q2FtcGFpZ246NQ== (admin user login details in password app).

The issue is that I expected to see a failure in the campaign exec results seeing as though a yarn-error.log file was produced.

What is also weird is that if I run a campaign targetting only one of these repositories such as lsp-client, the yarn-error.log file is not created and therefore not added to the diff.

To reproduce

NOTE: Requires access to a Sourcegraph instance that has synced affiliated repositories for the sd9 GitHub user.

Run an RxJS upgrade campaign for repos owned by the GitHub sd9 user using the commands:

git clone https://github.com/sourcegraph/campaign-examples.git
cd campaign-examples/rxjs-upgrade
make exec ACTION=sd9.action.json
make campaign-plan

Create a draft campaign and you should see multiple instances of yarn-error.log as part of the campaign diff.

Update binary release to reflect LSIF docs

A new src-cli binary release is needed because currently the LSIF quickstart instructions refer to messages like:

LSIF dump successfully uploaded. It will be converted asynchronously.
To check the status, visit <link to your Sourcegraph instance LSIF status>

But this is only seen if go get was used to get src-cli.

src-cli doesn't accept numeric arguments

Running the following command:

echo 'query DependencyReferences($repoPath: String!, $commitID: String!, $filePath: String!, $mode: String!, $line: Int!, $character: Int!) {
	repository(uri: $repoPath) {
	  commit(rev: $commitID) {
		file(path: $filePath) {
		  dependencyReferences(Language: $mode, Line: $line, Character: $character) {
			repoData {
			  repos {
				id
				uri
				lastIndexedRevOrLatest {
				  oid
				}
			  }
			  repoIds
			}
		  }
		}
	  }
	}
  }
  ' | src api 'repoPath=github.com/gorilla/mux' 'commitID=cb4698366aa625048f3b815af6a0dea8aef9280a' 'mode=go' 'filePath=mux.go' 'line=23' 'char=5'

Returns:

{
  "data": {
    "repository": {
      "commit": {
        "file": {}
      }
    }
  },
  "errors": [
    {
      "message": "could not unmarshal \"23\" (string) into int32: incompatible type"
    }
  ]
}

Is there a way to specify types for args?

(not urgent, just noticed this while working on sourcegraph/sourcegraph#11753)

config flag does not work

The CLI does not seem to respect the -config option. I created a config file that was not ~/src-config.json and updated it with a different endpoint, but the CLI continued to hit the original endpoint.

cli search: config option to use a different git-diff tool

Hi. Loving using src from the cli so far. One small improvement I'd love to see...

Is it possible for you to provide a way to customise which git diff syntax highlighter the src cli uses? Perhaps via a config setting? (Not sure if this is possible... I guess it depends how much the code depends on colordiff specifics)

I set up the cli and have colordiff working correctly. However I'd love to have src use delta for git diff highlighting.

I tried piping the output of src search ... type:diff to delta but that doesn't work of course as the format is a mix of git-diff and highlighted search results.

Extension publish command should warn user if repository field not set in package.json

The goal is to get as many extensions as possible with a repository object set in their package.json with the assumption that a legitimate extension will have a git repository.

One way to achieve this is to set it when the extension is bootstrapped by the extension creator (sourcegraph/create-extension#29) but another way is to prompt them with a message upon publishing.

I'm proposing that src extension publish would detect if the repository field was missing and display a message asking them to add the repository field in the future. It would not block the publishing process.

Confused by 405 error caused by src-config.json endpoint having a trailing slash

If the endpoint in the src-config.json has a trailing slash, a 405 method not allowed error is returned. I expected this to be handled gracefully.

Add `src actions create` command to create actions.json boilerplate

To help surface the actions schema and show different step examples, create a create-schema command which would create an action.json file in the current directory. I'd advise skipping the dumping it to stdout so the user can successfully do it the first time around without re-executing it with redirection to a file.

In the boilerplate file, a $schema field would be added to surface the schema.

This would make tutorial videos and instructions for creating an initial action.json file super easy and preconfiguring support for code completion and code doc hovers in VS Code would be really cool.

src ext delete should take extension ID, not GraphQL ID (which is confusing)

For a correctly configured extension, src ext publish succeeds, but src ext delete does not.

The error returned is:

GraphQL errors:
[
  {
    "message": "invalid graphql.ID",
    "path": [
      "extensionRegistry",
      "deleteExtension"
    ]
  }
]

pq: duplicate key value violates unique constraint error when trying to use src campaigns add-changeset

I am trying to add a bunch of changesets to a campaign that has no changesets (according to the UI and GraphQL API).

I am running this command:

 Get-GitHubPullRequest -Repository sourcegraph -Owner sourcegraph -State all | select-object -first 50 | % Number | % { src '-endpoint=http://localhost:3080' campaigns add-changesets '-campaign=Q2FtcGFpZ246MQ==' '-repo-name=github.com/sourcegraph/sourcegraph' $_ }

Which runs these commands:

src '-endpoint=http://localhost:3080' campaigns add-changesets '-campaign=Q2FtcGFpZ246MQ==' '-repo-name=github.com/sourcegraph/sourcegraph' 6007
src '-endpoint=http://localhost:3080' campaigns add-changesets '-campaign=Q2FtcGFpZ246MQ==' '-repo-name=github.com/sourcegraph/sourcegraph' 6006
src '-endpoint=http://localhost:3080' campaigns add-changesets '-campaign=Q2FtcGFpZ246MQ==' '-repo-name=github.com/sourcegraph/sourcegraph' 6005
src '-endpoint=http://localhost:3080' campaigns add-changesets '-campaign=Q2FtcGFpZ246MQ==' '-repo-name=github.com/sourcegraph/sourcegraph' 6003
src '-endpoint=http://localhost:3080' campaigns add-changesets '-campaign=Q2FtcGFpZ246MQ==' '-repo-name=github.com/sourcegraph/sourcegraph' 5993
src '-endpoint=http://localhost:3080' campaigns add-changesets '-campaign=Q2FtcGFpZ246MQ==' '-repo-name=github.com/sourcegraph/sourcegraph' 5991
src '-endpoint=http://localhost:3080' campaigns add-changesets '-campaign=Q2FtcGFpZ246MQ==' '-repo-name=github.com/sourcegraph/sourcegraph' 5990
...

But I am just getting this error printed every time:

GraphQL errors:
[
  {
    "message": "pq: duplicate key value violates unique constraint \"changesets_repo_external_id_unique\"",
    "path": [
      "createChangesets"
    ]
  }
]
GraphQL errors:
[
  {
    "message": "pq: duplicate key value violates unique constraint \"changesets_repo_external_id_unique\"",
    "path": [
      "createChangesets"
    ]
  }
]
...

It works after dropping my entire database.

Maybe changesets are soft deleted, but there is a unique constraint on it that would block re-adding after being soft-deleted?

src campaigns is not listed in help

This makes the command not discoverable and confused me when I wanted to try it (was I running the wrong version?).

Ideally this would be solved by architecting the code in a way that it is impossible to omit it, because the list of commands is dynamically generated.

docs: Show how to use actions schema with VS code for completion and hovers

Support filling in an extension's publisher

It would be nice if src extensions publish could fill in the publisher with the access token's username. This would make it easier for users who want to publish a "fork" or local dev copy of an extension. It would mean they would not need to temporarily edit package.json to add a "publisher": "jsmith" property (and remember to avoid committing their changes).

a8n: Doesn't support namespaced Docker image names e.g, sourcegraph/rxjs-upgrade

If using a Docker image name such as sourcegraph/rxjs-upgrade is used as the , the CLI will output an empty array [].

a8n: When the list of repos is too long for the terminal, the output breaks

See this recording:

There is a lot of flicker and when the status of a single repo is updated the flicker gets worse.

Add command for creating and saving access token in browser

It would be nice to automate the process of creating an access token and saving it to the src-config.json file, like how gcloud login works.

cc @ryan-blunden @attfarhan this came up when publishing an extension

Confused by 405 error caused by src-config.json endpoint having a trailing slash

If the endpoint in the src-config.json has a trailing slash, a 405 method not allowed error is returned. I expected this to be handled gracefully, or complain about incorrect configuration.

a8n: Steps should not be cached if the Docker image has been rebuilt. SHA needs to be checked, not just the tag

My development workflow was to re-build a Docker image with the same tag (latest) and if a repository had a diff previously created, it would skip running the steps over that repository, unless I changed the tag for the Docker image.

Document endpoint configuration in the README

Since almost everyone needs to do this, I think it should be documented in the README.

Support setting the WIP flag through the CLI when publishing an extension

Extension publishers should be able to set the extension as WIP by passing a flag through the CLI, without having to mention it in the extension name

`src extensions list` fails with a GraphQL error

When I try to list Sourcegraph extensions with src I get the following output:

$ SRC_ACCESS_TOKEN=<my_token> SRC_ENDPOINT=http://localhost:7080 src extensions list
GraphQL errors:
[
  {
    "locations": [
      {
        "column": 9,
        "line": 29
      }
    ],
    "message": "Cannot query field \"title\" on type \"ExtensionManifest\"."
  }
]

I'm using Sourcegraph 3.4.0-rc.5 running as a Docker container

a8n: Output shows duplicate lines when verbose flag is given

See this recording:

Don't fail actions exec if only a subset of repositories failed

This is from @christinaforney who was in a demo browser tab when creating this issue.

When I had failures in any repository, there was not a valid patches.json created for me (an empty file was created, but there were no diffs/content, so I couldn't push it to Sourcegraph to create the preview). This means that I'm completely blocked on starting a campaign until I resolve (or exclude) any failing repository.

Instead, I would like to be able to push up a valid patches.json from all of the repositories where my actions did not fail to preview and get started with kicking off my campaign. I can then come back to the failures to add them in later, so I should have a separate list (even just printed at the end) that tells me all the failed repos that I need to resolve. Some of the data we show already is good and helpful here, but we could summarize in a nicer way at finish, e.g. 3/10 repositories failed: <list repositories + links to error logs>. I can then push an update to my campaign once I've resolved each of these repositories (either caching the changes to repos that previously succeeded or by creating a way for me to add an individual diff for a repository to an existing campaign.

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Repository problems

These problems occurred while renovating this repository. View logs.

• WARN: Fallback to renovate.json file as a preset is deprecated, please use a default.json file instead.

Awaiting Schedule

These updates are awaiting their schedule. Click on a checkbox to get an update now.

• Update golang:1.22.3-alpine Docker digest to b8ded51
• Update alpine Docker tag to v3.20.0
• Update dependency bazel_gazelle to v0.37.0
• Update dependency io_bazel_rules_go to v0.48.0

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update dependency aspect_bazel_lib to v2.7.6
• Update dependency bazel_skylib to v1.6.1

Detected dependencies

asdf

.tool-versions

• golang 1.22.3
• shfmt 3.8.0
• shellcheck 0.10.0

bazel

WORKSPACE

• bazel_skylib 1.5.0
• aspect_bazel_lib v2.7.0
• io_bazel_rules_go v0.47.1
• bazel_gazelle v0.36.0

dockerfile

Dockerfile

• golang 1.22.3-alpine@sha256:df479aa7d1298917c7de7fd56c7231ec450149f1e63d960ea96aebf9ff9240c5
• sourcegraph/alpine 3.12@sha256:ce099fbcd3cf70b338fc4cb2a4e1fa9ae847de21afdb0a849a393b87d94fb174

Dockerfile.release

• sourcegraph/alpine 3.12@sha256:ce099fbcd3cf70b338fc4cb2a4e1fa9ae847de21afdb0a849a393b87d94fb174

docker/batch-change-volume-workspace/Dockerfile

• alpine 3.19.1@sha256:c5b1261d6d3e43071626931fc004f70149baeba2c8ec672bd4f27761f8e1ad6b

github-actions

.github/workflows/docker.yml

• actions/checkout v4
• docker/setup-buildx-action v3
• docker/setup-qemu-action v3
• ubuntu 22.04

.github/workflows/go-ci.yml

• actions/checkout v4
• actions/setup-go v5

.github/workflows/go-lint.yml

• actions/checkout v4
• actions/setup-go v5

.github/workflows/goreleaser-check.yml

• actions/checkout v4
• actions/setup-go v5
• goreleaser/goreleaser-action v5

.github/workflows/goreleaser.yml

• actions/checkout v4
• actions/checkout v4
• actions/checkout v4
• actions/checkout v4
• actions/setup-go v5
• goreleaser/goreleaser-action v5
• actions/checkout v4
• actions/checkout v4
• actions/setup-node v4

.github/workflows/pr-auditor.yml

• actions/checkout v4
• actions/setup-go v5

.github/workflows/scip.yml

• actions/checkout v4

gomod

go.mod

npm

npm-distribution/package.json

• tar ^7.1.0
• @types/tar 6.1.13

---

• Check this box to trigger a request for Renovate to run again on this repository

src config commands fail with graphql errors

$ src config list
GraphQL errors:
[
  {
    "locations": [
      {
        "column": 9,
        "line": 8
      }
    ],
    "message": "Fragment \"ConfigurationSubjectFields\" cannot be spread here as objects of type \"SettingsSubject\" can never be of type %!q(\u003cnil\u003e)."
  },
  {
    "locations": [
      {
        "column": 40,
        "line": 15
      }
    ],
    "message": "Unknown type \"ConfigurationSubject\"."
  },
  {
    "locations": [
      {
        "column": 13,
        "line": 20
      }
    ],
    "message": "Fragment \"ConfigurationFields\" cannot be spread here as objects of type %!q(\u003cnil\u003e) can never be of type \"Configuration\"."
  },
  {
    "locations": [
      {
        "column": 13,
        "line": 23
      }
    ],
    "message": "Fragment \"UserFields\" cannot be spread here as objects of type %!q(\u003cnil\u003e) can never be of type \"User\"."
  }
]

cc @attfarhan @vanesa

add ability to verify e.g. all user's emails en-mass

Remove inline dockerfile option

I like the intention behind making it super simple to run a container without creating a Dockerfile, but what's the likelihood of this being used in a content change scenario?

The example used in the docs is valid for sure, but couldn't this be achieved by specifying alpine:3 as the image, then supplying the CMD in the example as args instead?

Removing the option to me would simplify things, and allow code to be removed, all without losing functionality (just needs to be done in a different way).

a8n: Hitting `Ctrl-C` when running `src action exec` doesn't kill spawned containers

search and scopeQuery return different number of results

Wanted to construct a scope query that returned the sourcegraph and basic-code-intel repos.

The following search returns 2 results using src search but only one result when using scopeQuery:

repo:github\.com\/sourcegraph\/sourcegraph$|basic-code-intel$ repohasfile:yarn.lock file:^package.json$ rxjs patterntype:regexp

a8n: Cannot use `count` in `scopeQuery`

The error returned is type error at character 71: field count may not be used more than once.

Download links in README are broken

Add support for sudo tokens

Deprecate config file

To be aligned with what other tools do, I want to propose that we rename the src-cli config file to a hidden file.

See discussion below, we've decided to deprecate the config file.

Binary download broken on 3.12.5

1. Ensure 3.12.5 is the current version.
2. Request binary from the instance (https://a8n-demo.sgdev.org/.api/src-cli/src_linux_amd64)
3. Observe that the redirect URL is interpreted by Sourcegraph as a repo search (https://a8n-demo.sgdev.org/github.com/sourcegraph/src-cli/releases/download/3.10.3/src_linux_amd64)

src ext get fails with error

> src ext get felixfbecker/lang-typescript
GraphQL errors:
[
  {
    "locations": [
      {
        "column": 9,
        "line": 25
      }
    ],
    "message": "Cannot query field \"title\" on type \"ExtensionManifest\"."
  }
]

a8n: Need command to either run automation ignoring the cache and/or deleting the cache

src user create is broken (old GraphQL field)

src-cli/cmd/src/users_create.go

Line 38 in 73c0933

createUserBySiteAdmin(

This mutation seems to have been renamed to createUser

Diff produced by src actions exec doesn't respect gitignore

It seems that auto-generated files that are ignored by .gitignore such as schema files still make there way into a campaign plan.

To reproduce:

git clone https://github.com/sourcegraph/campaign-examples.git
cd campaign-examples/rxjs-upgrade
make exec # You may want to change the scopeQuery to just be sourcegraph
make campaign-plan

Follow the link to view the campaign plan in the UI and observe schema files in the diff ( see this example campaign on sgdemo).

high-value low-effort work

Posting this for visibility, actual tracking issue is in our monorepo here: sourcegraph/sourcegraph#3231

Automated upgrading

Now that the CLI is more important and used to publish extension we should make updating it easier. It should be possible to install with package managers like Homebrew, Chocolatey or apt. It should be as easy as it is to update PSSourcegraph :)

Improve how errors are reported

This issue is about printing out error messages that are more nicely formatted, not about fixing any specific error message. See #20 for context.

src repos list tries to use removed GQL repository fields enabled/disabled

qz:~/src/github.com/sourcegraph/src-cli $ src repo list
GraphQL errors:
[
  {
    "locations": [
      {
        "column": 5,
        "line": 17
      }
    ],
    "message": "Unknown argument \"enabled\" on field \"repositories\" of type \"Query\"."
  },
  {
    "locations": [
      {
        "column": 5,
        "line": 18
      }
    ],
    "message": "Unknown argument \"disabled\" on field \"repositories\" of type \"Query\"."
  }
]

Document access token configuration in the README

Since everyone needs to do this, I think it should be documented in the README.

Use JSON schema to validate that a given action definition is valid

Right now we validate in code, but now that we have a JSON schema (#149) we should use that to validate the action definition.

src extensions publish does not work correctly on Windows

src-cli/cmd/src/extensions_publish.go

Line 174 in 4e548d9

cmd := exec.Command("bash", "-c", o.Scripts.SourcegraphPrepublish)

The expected behaviour here would be what npm does, which is using cmd on Windows. This decision is automatically made by Node child_process.exec().

src-cli/cmd/src/extensions_publish.go

Line 175 in 4e548d9

cmd.Env = append(os.Environ(), fmt.Sprintf("PATH=%s:%s", filepath.Join(dir, "node_modules", ".bin"), os.Getenv("PATH")))

Windows uses ; to separate PATH, not :.

Unzip failed with interactive message

unzip version: UnZip 6.00 of 20 April 2009, by Info-ZIP. Maintained by C. Spieler.
OS: macOS Catalina 10.15.3
Error log:

Unzipping the ZIP archive failed: unzip failed: exit status 1: replace /tmp/action-sd9-akita694954415/angular/playground/projects/ng-entity-service/src/lib/ng-entity-service-notifier.ts? [y]es, [n]o, [A]ll, [N]one, [r]ename:  NULL
(EOF or read error, treating as "[N]one" ...)

# Repository github.com/sd9/akita @ refs/heads/master (1 steps)
# ERROR: Unzipping the ZIP archive failed: unzip failed: exit status 1: replace /tmp/action-sd9-akita391331449/angular/playground/projects/ng-entity-service/src/lib/ng-entity-service-notifier.ts? [y]es, [n]o, [A]ll, [N]one, [r]ename:  NULL
(EOF or read error, treating as "[N]one" ...)

action file:

{
  "scopeQuery": "repo:github.com/sd9/* repohasfile:^package.json",
  "steps": [
    {
      "type": "command",
      "args": ["sed", "-i", "", "s/\"main\"/\"es2015\"/", "package.json"]
    }
  ]
}

src extension publish errors with unclear action to take

I just tried to publish an extension and just got an unhelpful JSON dump of a GraphQL error:

GraphQL errors:
[
  {
    "message": "registry extension publisher not found: [name felixfbecker]",
    "path": [
      "extensionRegistry",
      "publishExtension"
    ]
  }
]

I don't know how to resolve this, and I think the JSON dumping is a bit lazy. Since GraphQL errors have a known schema, we can pretty print these errors, otherwise as a user I get the impression that I ran into an unexpected bug instead of an expected condition that I can resolve.

As an inspiration, I think PSSourcegraph does a slightly better job here:

✔ ~/src/github.com/sourcegraph/enterprise [master ≡]
> Search-Sourcegraph 'foo:bar'
Invoke-SourcegraphApiRequest : type error at character 0: unrecognized field "foo"
At search
At /Users/felix/.local/share/powershell/Modules/PSSourcegraph/0.0.5/src/search.psm1:24 char:13
+     $data = Invoke-SourcegraphApiRequest -Query $SearchQuery -Variabl ...
+             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (:) [Write-Error], Exception
+ FullyQualifiedErrorId : System.Exception,Invoke-SourcegraphApiRequest
✔ ~/src/github.com/sourcegraph/enterprise [master ≡]
> Enable-SourcegraphRepository -Id 'askdjaslkdasdasd'
Invoke-SourcegraphApiRequest : invalid graphql.ID
At setRepositoryEnabled
At /Users/felix/.local/share/powershell/Modules/PSSourcegraph/0.0.5/src/repos.psm1:58 char:5
+     Invoke-SourcegraphApiRequest -Query $setRepositoryEnabledQuery -V ...
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (:) [Write-Error], Exception
+ FullyQualifiedErrorId : System.Exception,Invoke-SourcegraphApiRequest

Note how the GraphQL error message gets used as the exception message and the path is used to provide a dot-joined trace at what field the error occurred.

Allow/control read-only access

Access token options now are (1) full access as a given user, (2) full access as anyone.

The discussion of documenting access tokens mentions in passing that you don't need to log in to use sourcegraph.com in general. It seems like it might make sense to have a configuration flag for whether or not to permit tokenless read-only access, but also to have a way to generate read-only tokens which aren't allowed to do things.

This is really hard. Consider a hypothetical attacker who finds out about a thing that can be triggered if they can induce your sourcegraph instance to do a git fetch of a repo; a "read-only" token that can cause fetches is still a vulnerability. But it'd be nice to have, if we could do it.