docs: Reflect code file path changes by kubernetes-sigs#101

pkg/plugins/config.go

@@ -54,7 +54,7 @@ type Configuration struct {
 	// If it is defined on both organization and repository levels, the list of enabled
 	// plugin names for the repository is the merging list of the two levels.
 	// You can find a comprehensive list of the default available plugins here
-	// https://github.com/kubernetes-sigs/prow/tree/main/prow/plugins
+	// https://github.com/kubernetes-sigs/prow/tree/main/pkg/plugins
 	// note that you're also able to add external plugins.
 	Plugins Plugins `json:"plugins,omitempty"`
 

pkg/plugins/plugin-config-documented.yaml

@@ -486,7 +486,7 @@ owners:
 # If it is defined on both organization and repository levels, the list of enabled
 # plugin names for the repository is the merging list of the two levels.
 # You can find a comprehensive list of the default available plugins here
-# https://github.com/kubernetes-sigs/prow/tree/main/prow/plugins
+# https://github.com/kubernetes-sigs/prow/tree/main/pkg/plugins
 # note that you're also able to add external plugins.
 plugins:
     "":

site/content/en/docs/build-test-update.md

@@ -33,7 +33,7 @@ go build ./prow/cmd/hook
 go test ./prow/plugins/lgtm
 ```
 (Note: `deck` depends on non-go static files, these were tested by integration
-tests, and for e2e test use [`runlocal`](https://github.com/kubernetes-sigs/prow/tree/main/prow/cmd/deck/runlocal) if desired.)
+tests, and for e2e test use [`runlocal`](https://github.com/kubernetes-sigs/prow/blob/main/cmd/deck/runlocal) if desired.)
 
 ### How to test a plugin
 

site/content/en/docs/components/cli-tools/phony.md

@@ -50,4 +50,4 @@ If you are testing `hook` and successfully sent the webhook from `phony`, you sh
 {"author":"","component":"hook","event-GUID":"GUID","event-type":"pull_request","level":"info","msg":"Pull request .","org":"","pr":0,"repo":"","time":"2018-05-29T11:38:57-07:00","url":""}
 ```
 
-A list of supported events can be found in the [GitHub API Docs](https://developer.github.com/v3/activity/events/types/). Some example event payloads can be found in the [`examples`](https://github.com/kubernetes-sigs/prow/tree/main/prow/cmd/phony/examples) directory.
+A list of supported events can be found in the [GitHub API Docs](https://developer.github.com/v3/activity/events/types/). Some example event payloads can be found in the [`examples`](https://github.com/kubernetes-sigs/prow/tree/main/cmd/phony/examples) directory.

site/content/en/docs/components/core/crier.md

@@ -12,7 +12,7 @@ Crier reports your prowjobs on their status changes.
 For any reporter you want to use, you need to mount your prow configs and specify `--config-path` and `job-config-path`
 flag as most of other prow controllers do.
 
-### [Gerrit reporter](https://github.com/kubernetes-sigs/prow/tree/main/prow/crier/reporters/gerrit)
+### [Gerrit reporter](https://github.com/kubernetes-sigs/prow/tree/main/pkg/crier/reporters/gerrit)
 
 You can enable gerrit reporter in crier by specifying `--gerrit-workers=n` flag.
 
@@ -27,7 +27,7 @@ The reporter will also cast a +1/-1 vote on the `prow.k8s.io/gerrit-report-label
 or by default it will vote on `CodeReview` label. Where `+1` means all jobs on the patshset pass and `-1`
 means one or more jobs failed on the patchset.
 
-### [Pubsub reporter](https://github.com/kubernetes-sigs/prow/tree/main/prow/crier/reporters/pubsub)
+### [Pubsub reporter](https://github.com/kubernetes-sigs/prow/tree/main/pkg/crier/reporters/pubsub)
 
 You can enable pubsub reporter in crier by specifying `--pubsub-workers=n` flag.
 
@@ -45,17 +45,17 @@ Pubsub reporter will report whenever prowjob has a state transition.
 
 You can check the reported result by [list the pubsub topic](https://cloud.google.com/sdk/gcloud/reference/pubsub/topics/list).
 
-### [GitHub reporter](https://github.com/kubernetes-sigs/prow/tree/main/prow/crier/reporters/github)
+### [GitHub reporter](https://github.com/kubernetes-sigs/prow/tree/main/pkg/crier/reporters/github)
 
 You can enable github reporter in crier by specifying `--github-workers=N` flag (N>0).
 
 You also need to mount a github oauth token by specifying `--github-token-path` flag, which defaults to `/etc/github/oauth`.
 
 If you have a [ghproxy](https://github.com/kubernetes-sigs/prow/tree/main/ghproxy) deployed, also remember to point `--github-endpoint` to your ghproxy to avoid token throttle.
 
-The actual report logic is in the [github report library](https://github.com/kubernetes-sigs/prow/tree/main/prow/github/report) for your reference.
+The actual report logic is in the [github report library](https://github.com/kubernetes-sigs/prow/tree/main/pkg/github/report) for your reference.
 
-### [Slack reporter](https://github.com/kubernetes-sigs/prow/tree/main/prow/crier/reporters/slack)
+### [Slack reporter](https://github.com/kubernetes-sigs/prow/tree/main/pkg/crier/reporters/slack)
 
 > **NOTE:** if enabling the slack reporter for the *first* time, Crier will message to the Slack channel for **all** ProwJobs matching the configured filtering criteria.
 

site/content/en/docs/components/plugins/_index.md

@@ -35,7 +35,7 @@ External plugins are well suited for:
 - Isolating a more or less privileged plugin or a plugin that executes PR code.
 - Integrating existing GitHub services with Prow.
 
-Examples of external plugins can be found in the [`prow/external-plugins`](https://github.com/kubernetes-sigs/prow/tree/main/prow/external-plugins) directory. The following is an example external plugin configuration that would live in [`plugins.yaml`](https://github.com/kubernetes/test-infra/blob/master/config/prow/plugins.yaml).
+Examples of external plugins can be found in the [`prow/external-plugins`](https://github.com/kubernetes-sigs/prow/tree/main/cmd/external-plugins) directory. The following is an example external plugin configuration that would live in [`plugins.yaml`](https://github.com/kubernetes/test-infra/blob/master/config/prow/plugins.yaml).
 
 ```yaml
 external_plugins:

site/content/en/docs/gerrit.md

@@ -9,14 +9,14 @@ description: >
 
 ## Related Deployments
 
-- Prow-gerrit adapter ([doc](/docs/components/optional/gerrit/), [code](https://github.com/kubernetes-sigs/prow/tree/main/prow/cmd/gerrit))
-- Crier (the reporter) ([doc](/docs/components/core/crier/), [code](https://github.com/kubernetes-sigs/prow/tree/main/prow/cmd/crier))
+- Prow-gerrit adapter ([doc](/docs/components/optional/gerrit/), [code](https://github.com/kubernetes-sigs/prow/tree/main/cmd/gerrit))
+- Crier (the reporter) ([doc](/docs/components/core/crier/), [code](https://github.com/kubernetes-sigs/prow/tree/main/cmd/crier))
 
 ## Related packages
 
 #### Client
 
-We have a [gerrit-client package](https://github.com/kubernetes-sigs/prow/tree/main/prow/gerrit/client) that provides a thin wrapper around  
+We have a [gerrit-client package](https://github.com/kubernetes-sigs/prow/tree/main/pkg/gerrit/client) that provides a thin wrapper around 
 [andygrunwald/go-gerrit](https://github.com/andygrunwald/go-gerrit), which is a go client library
 for accessing the [Gerrit Code Review REST API](https://gerrit-review.googlesource.com/Documentation/rest-api.html)
 

site/content/en/docs/spyglass/architecture.md

@@ -12,7 +12,7 @@ with artifacts.
 
 ## Spyglass Core
 
-The Spyglass Core is split across [`prow/spyglass`](https://github.com/kubernetes-sigs/prow/tree/main/prow/spyglass) and [`prow/cmd/deck`](https://github.com/kubernetes-sigs/prow/tree/main/prow/cmd/deck). It has
+The Spyglass Core is split across [`prow/spyglass`](https://github.com/kubernetes-sigs/prow/tree/main/pkg/spyglass) and [`prow/cmd/deck`](https://github.com/kubernetes-sigs/prow/tree/main/cmd/deck). It has
 the following responsibilities:
 
 - Looking up artifacts for a given job and mapping those to lenses
@@ -22,7 +22,7 @@ the following responsibilities:
 
 ## Spyglass Lenses
 
-Spyglass Lenses currently all live in [`prow/spyglass/lenses`](https://github.com/kubernetes-sigs/prow/tree/main/prow/spyglass/lenses), though hopefully in the
+Spyglass Lenses currently all live in [`prow/spyglass/lenses`](https://github.com/kubernetes-sigs/prow/tree/main/pkg/spyglass/lenses), though hopefully in the
 future they can live elsewhere. Spyglass lenses have the following responsibilities:
 
 - Fetching artifacts

site/content/en/docs/spyglass/write-a-lens.md

@@ -10,7 +10,7 @@ Spyglass lenses consist of two components: a frontend (which may be trivial) and
 ## Lens backend
 
 Today, a lens backend must be linked in to the `deck` binary. As such, lenses must live under
-[`prow/spyglass/lenses`](https://github.com/kubernetes-sigs/prow/tree/main/prow/spyglass/lenses). Additionally lenses **must** be in a folder that matches the
+[`prow/spyglass/lenses`](https://github.com/kubernetes-sigs/prow/tree/main/pkg/spyglass/lenses). Additionally lenses **must** be in a folder that matches the
 name of the lens. The content of this folder will be served by `deck`, enabling you to reference
 static content such as images, stylesheets, or scripts.
 

site/content/en/docs/test/integration/_index.md

@@ -60,7 +60,7 @@ Assume we want to add `most-awesome-component` (source code in `prow/cmd/most-aw
 
 ## New tests
 
-Tests are written under the [`test`](https://github.com/kubernetes-sigs/prow/tree/main/prow/test/integration/test) directory. They are named with the
+Tests are written under the [`test`](https://github.com/kubernetes-sigs/prow/tree/main/test/integration/test) directory. They are named with the
 pattern `<COMPONENT>_test.go*`. Continuing the example above, you would add new
 tests in `most-awesome-component_test.go`