github.com/munnerz/test-infra@v0.0.0-20190108210205-ce3d181dc989/prow/build_test_update.md (about)

     1  # Building, Testing, and Updating Prow
     2  
     3  This guide is directed at Prow developers and maintainers who want to build/test individual components or deploy changes to an existing Prow cluster. [`getting_started_deploy.md`](/prow/getting_started_deploy.md) is a better reference for deploying a new Prow cluster.
     4  
     5  ## How to build and test Prow
     6  
     7  You can build, test, and deploy Prow’s binaries, container images, and cluster resources using [`bazel`](https://bazel.build).
     8  
     9  Build with:
    10  ```shell
    11  bazel build //prow/...
    12  ```
    13  Test with:
    14  ```shell
    15  bazel test --features=race //prow/...
    16  ```
    17  Individual packages and components can be built and tested like:
    18  ```shell
    19  bazel build //prow/cmd/hook
    20  bazel test //prow/plugins/lgtm:go_default_test
    21  ```
    22  
    23  **TODO**(cjwagner): Unify and document how to run prow components locally.
    24  
    25  ## How to test a ProwJob
    26  
    27  The best way to go about testing a new ProwJob depends on the job itself. If the
    28  job's test container can be run locally that is typically the best way to
    29  initially test the job because local debugging is easier than debugging a job in
    30  CI.
    31  
    32  Actually running the job on Prow is the next step. Before Prow can run your job,
    33  you'll need to supply the job's config. Typically, new presubmit jobs
    34  are configured to `skip_report`ing to GitHub and may not be configured to 
    35  automatically run on every PR with `always_run: true`. Once the job is stable
    36  these values can be changed to make the job run everywhere and become visible
    37  to users by posting results to GitHub (if desired).
    38  Changes to existing jobs can be trialed on canary jobs.
    39  
    40  ### How to manually run a given job on prow
    41  
    42  If the normal job triggering mechanisms (`/test foo` comments, PR changes, PR
    43  merges, cron schedule) are not sufficient for your testing you can use `mkpj` to
    44  manually trigger new ProwJob runs.
    45  To manually trigger any ProwJob, run the following, specifying `JOB_NAME`:
    46  
    47  For K8S Prow, you can trigger a job by running
    48  ```shell
    49  bazel run //config:mkpj -- --job=JOB_NAME
    50  ```
    51  
    52  For your own prow instance, you can either define your own bazel rule, or
    53  just go run mkpj like:
    54  ```shell
    55  go run k8s.io/test-infra/prow/cmd/mkpj --job=JOB_NAME --config-path=path/to/config.yaml
    56  ```
    57  
    58  Alternatively, if you have jobs defined in a separate `job-config`, you can
    59  specify the config by adding the flag `--job-config-path=path/to/job/config.yaml`.
    60  
    61  This will print the ProwJob YAML to stdout. You may pipe it into `kubectl`.
    62  Depending on the job, you will need to specify more information such as PR
    63  number.
    64  
    65  NOTE: It is dangerous to create ProwJobs from handcrafted YAML. Please use `mkpj`
    66  to generate ProwJob YAML.
    67  
    68  ## How to update the cluster
    69  
    70  Any modifications to Go code will require redeploying the affected binaries.
    71  Assuming your prow components have multiple replicas, this will result in no downtime.
    72  
    73  Update your deployment (optionally build/pushing the image) to a new image with:
    74  ```shell
    75  # export PROW_REPO_OVERRIDE=gcr.io/k8s-prow  # optionally override project
    76  bump.sh --list  # Choose a recent published version
    77  bump.sh --push  # Build and push the current repo state (and use this version).
    78  bump.sh v20181002-deadbeef # Use a specific version
    79  ```
    80  
    81  Once your deployment files are updated, please update these resources on your cluster:
    82  
    83  ```shell
    84  # Set the kubectl context you want to use
    85  export STABLE_PROW_CLUSTER=gke_my-project_my-zone_my-cluster # or whatever the correct value is
    86  # Generally just do
    87  bazel run //prow/cluster:production.apply # deploy everything
    88  
    89  # In case of an emergency hook update
    90  bazel run //prow/cluster:hook.apply # just update hook
    91  
    92  # This is equivalent to doing the following with kubectl directly:
    93  kubectl config use-context gke_my-project_my-zone_my-cluster
    94  kubectl apply -f prow/cluster/*.yaml
    95  kubectl apply -f prow/cluster/hook_deployment.yaml
    96  ```