Source secret dialog

.gitignore

@@ -7,8 +7,8 @@
 /Godeps/_workspace/src/github.com/openshift/console
 /frontend/.cache-loader
 /frontend/__coverage__
+/frontend/**/node_modules
 /frontend/public/bower_components
-/frontend/node_modules
 /frontend/public/dist
 /frontend/npm-debug.log
 /frontend/yarn-error.log

CONTRIBUTING.md

@@ -6,6 +6,7 @@ This document outlines some of the conventions on development workflow.
 
 - Fork the repository on GitHub
 - Read the [README](README.md) for build and test instructions
+- Read the [STYLEGUIDE](STYLEGUIDE.md) for code conventions
 - Play with the project, submit bugs, submit patches!
 
 ## Contribution Flow
@@ -57,22 +58,18 @@ issue to its pull request and close the issue when the pull request merges.
 While we don't have automated tooling for JIRA issues, you should still include
 a link to the issue in the commit description to make it easy to get to the issue.
 
-### Pull Requests Against Other Branches
+### Backporting Fixes
 
-Pull requests opened against branches other than master should start the pull
-request title with the branch name in brackets like `[release-3.11]` to make it
-obvious. Include the bug as well when appropriate. For instance,
+Branches for previous releases follow the format `release-X.Y`, for example,
+`release-4.1`. Typically, bugs are fixed in the master branch first then
+backported to the appropriate release branches. Fixes backported to previous
+releases should have a Bugzilla bug for each version fixed.
 
-```
-[release-3.11] Bug 1643948: Fix crashlooping pods query
-```
-
-If you use the `/cherrypick` command, the bot will automatically append the
-branch to the pull request title. For instance, adding a comment to a PR like
+You can use the `/cherrypick` command to ask the bot to backport a fix.
 
 ```
-/cherrypick release-3.11
+/cherrypick release-4.1
 ```
 
-will create a new pull request against the release-3.11 branch when the current
+will create a new pull request against the release-4.1 branch when the current
 pull request merges as long as there are no merge conflicts.

Dockerfile

@@ -1,4 +1,4 @@
-FROM quay.io/coreos/tectonic-console-builder:v16 AS build
+FROM quay.io/coreos/tectonic-console-builder:v17 AS build
 
 RUN mkdir -p /go/src/github.com/openshift/console/
 ADD . /go/src/github.com/openshift/console/

Dockerfile.builder

@@ -0,0 +1,55 @@
+# Used for compiling the tectonic-console. After editing this file,
+# (and committing your edits) you should run ./push-builder.sh to
+# push a new version of your image to quay.io/coreos/tectonic-console-builder
+
+FROM golang:1.11-stretch
+
+MAINTAINER Ed Rooth - CoreOS
+
+### For golang testing stuff
+RUN go get -u github.com/golang/lint/golint
+RUN go get github.com/jstemmer/go-junit-report
+
+### Install NodeJS and yarn
+ENV NODE_VERSION="v10.3.0"
+ENV YARN_VERSION="v1.7.0"
+
+# yarn needs a home writable by any user running the container
+ENV HOME /opt/home
+RUN mkdir -p ${HOME}
+RUN chmod 777 -R ${HOME}
+
+RUN apt-get update \
+    && apt-get install --no-install-recommends -y -q \
+    curl wget git unzip bzip2 jq
+
+RUN curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.8.2/bin/linux/amd64/kubectl && \
+    chmod +x ./kubectl && \
+    mv ./kubectl /usr/local/bin/kubectl
+
+RUN cd /tmp && \
+    wget --quiet -O /tmp/node.tar.gz http://nodejs.org/dist/${NODE_VERSION}/node-${NODE_VERSION}-linux-x64.tar.gz && \
+    tar xf node.tar.gz && \
+    rm -f /tmp/node.tar.gz && \
+    cd node-* && \
+    cp -r lib/node_modules /usr/local/lib/node_modules && \
+    cp bin/node /usr/local/bin && \
+    ln -s /usr/local/lib/node_modules/npm/bin/npm-cli.js /usr/local/bin/npm
+# so any container user can install global node modules if needed
+RUN chmod 777 /usr/local/lib/node_modules
+# cleanup
+RUN rm -rf /tmp/node-v*
+
+RUN cd /tmp && \
+    wget --quiet -O /tmp/yarn.tar.gz https://github.com/yarnpkg/yarn/releases/download/${YARN_VERSION}/yarn-${YARN_VERSION}.tar.gz && \
+    tar xf yarn.tar.gz && \
+    rm -f /tmp/yarn.tar.gz && \
+    mv /tmp/yarn-${YARN_VERSION} /usr/local/yarn && \
+    ln -s /usr/local/yarn/bin/yarn /usr/local/bin/yarn
+
+# Install Chrome for installer gui tests
+RUN wget --quiet -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add - && \
+    sh -c 'echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google-chrome.list' && \
+    apt-get update && \
+    apt-get install --no-install-recommends -y -q \
+    google-chrome-stable ca-certificates

README.md

@@ -17,30 +17,32 @@ The console is a more friendly `kubectl` in the form of a single page webapp.  I
 ### Dependencies:
 
 1. [node.js](https://nodejs.org/) >= 8 & [yarn](https://yarnpkg.com/en/docs/install) >= 1.3.2
-2. [go](https://golang.org/) >= 1.8 & [glide](https://glide.sh/) >= 0.12.0 (`go get github.com/Masterminds/glide`) & [glide-vc](https://github.com/sgotti/glide-vc)
-3. [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) and a k8s cluster
+2. [go](https://golang.org/) >= 1.11+
+3. [oc](https://mirror.openshift.com/pub/openshift-v4/clients/oc/4.1/) or [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) and an OpenShift or Kubernetes cluster
 4. `jq` (for `contrib/environment.sh`)
 5. Google Chrome/Chromium >= 60 (needs --headless flag) for integration tests
 
 ### Build everything:
 
+This project uses uses [Go modules](https://github.com/golang/go/wiki/Modules),
+so you should clone the project outside of your `GOPATH`. To build both the
+frontend and backend, run:
+
 ```
 ./build.sh
 ```
 
-Backend binaries are output to `/bin`.
-
+Backend binaries are output to `./bin`.
 
 ### Configure the application
 
 The following instructions assume you have an existing cluster you can connect
-to. OpenShift 4.0 clusters can be installed using the
-[OpenShift Installer](https://github.com/openshift/installer).
-You can also use [CodeReady Containers](https://github.com/code-ready/osp4)
+to. OpenShift 4.x clusters can be installed using the
+[OpenShift Installer](https://mirror.openshift.com/pub/openshift-v4/clients/ocp/latest/).
+You can also use [CodeReady Containers](https://github.com/code-ready/crc)
 for local installs. More information about installing OpenShift can be found at
 <https://try.openshift.com/>.
 
-
 #### OpenShift (no authentication)
 
 For local development, you can disable OAuth and run bridge with an OpenShift
@@ -132,7 +134,7 @@ See [STYLEGUIDE](STYLEGUIDE.md) for file format and coding style guide.
 
 ### Dev Dependencies
 
-go, glide, glide-vc, nodejs/yarn, kubectl
+go 1.11+, nodejs/yarn, kubectl
 
 ### Frontend Development
 
@@ -184,8 +186,6 @@ Run frontend tests:
 
 Integration tests are run in a headless Chrome driven by [protractor](http://www.protractortest.org/#/).  Requirements include Chrome, a working cluster, kubectl, and bridge itself (see building above).
 
-Note: If you are running integration tests against OpenShift, you should start bridge using [oc-environment.sh](#openshift-without-oauth) to skip the login page.
-
 Setup (or any time you change node_modules - `yarn add` or `yarn install`)
 ```
 cd frontend && yarn run webdriver-update
@@ -214,9 +214,10 @@ CI runs the [test-prow-e2e.sh](test-prow-e2e.sh) script, which uses the `e2e` su
 You can simulate an e2e run against an existing 4.0 cluster with the following commands (replace `/path/to/install-dir` with your OpenShift 4.0 install directory):
 
 ```
-$ export BRIDGE_AUTH_USERNAME=kubeadmin
-$ export BRIDGE_BASE_ADDRESS="https://$(oc get route console -n openshift-console -o jsonpath='{.spec.host}')"
-$ export BRIDGE_AUTH_PASSWORD=$(cat "/path/to/install-dir/auth/kubeadmin-password")
+$ oc apply -f ./frontend/integration-tests/data/htpasswd-secret.yaml
+$ oc patch oauths cluster --patch "$(cat ./frontend/integration-tests/data/patch-htpasswd.yaml)" --type=merge
+$ export BRIDGE_BASE_ADDRESS="$(oc get consoles.config.openshift.io cluster -o jsonpath='{.status.consoleURL}')"
+$ export BRIDGE_KUBEADMIN_PASSWORD=$(cat "/path/to/install-dir/auth/kubeadmin-password")
 $ ./test-gui.sh e2e
 ```
 
@@ -234,12 +235,54 @@ Remove the `--headless` flag to Chrome (chromeOptions) in [protractor.conf.ts](f
 
 1. `cd frontend; yarn run build`
 2. Add `debugger;` statements to any e2e test
-3. `yarn run debug-test-suite --suite overview`
+3. `yarn run debug-test-suite --suite <suite-to-debug>`
 4. Chrome browser URL: 'chrome://inspect/#devices', click on the 'inspect' link in **Target (v10...)** section.
 5. Launches chrome-dev tools, click Resume button to continue
 6. Will break on any `debugger;` statements
 7. Pauses browser when not using `--headless` argument!
 
+### Deploying a Custom Image to an OpenShift Cluster
+
+Once you have made changes locally, these instructions will allow you to push
+changes to an OpenShift cluster for others to review.  This involves building a
+local image, pushing the image to an image registry, then updating the
+OpenShift cluster to pull the new image.
+
+#### Prerequisites
+
+1. Docker v17.05 or higher for multi-stage builds
+2. An image registry like [quay.io](https://quay.io/signin/) or [Docker Hub](https://hub.docker.com/)
+
+#### Steps
+1. Create a repository in the image registry of your choice to hold the image.
+2. Build Image `docker build -t <your-image-name> <path-to-repository | url>`. For example:
+```
+docker build -t quay.io/myaccount/console:latest .
+```
+3. Push image to image registry `docker push <your-image-name>`.  Make sure
+   docker is logged into your image registry! For example:
+```
+docker push quay.io/myaccount/console:latest
+```
+4. Put the console operator in unmanaged state:
+```
+oc patch consoles.operator.openshift.io cluster --patch '{ "spec": { "managementState": "Unmanaged" } }' --type=merge
+```
+5. Update the console Deployment with the new image:
+```
+oc set image deploy console console=quay.io/myaccount/console:latest -n openshift-console
+```
+6. Wait for the changes to rollout:
+```
+oc rollout status -w deploy/console -n openshift-console
+```
+You should now be able to see your development changes on the remote OpenShift cluster!
+
+When done, you can put the console operator back in a managed state to remove the custom image:
+```
+oc patch consoles.operator.openshift.io cluster --patch '{ "spec": { "managementState": "Managed" } }' --type=merge
+```
+
 ### Dependency Management
 
 Dependencies should be pinned to an exact semver, sha, or git tag (eg, no ^).
@@ -251,14 +294,10 @@ Whenever making vendor changes:
 2. Commit everything *except* `vendor/` (eg, `server: add x feature`)
 3. Make a second commit with only `vendor/` (eg, `vendor: revendor`)
 
-Add new backend dependencies:
- 1. Edit `glide.yaml`
- 2. `./revendor.sh`
-
-Update existing backend dependencies:
- 1. Edit the `glide.yaml` file to the desired version (most likely a git hash)
- 2. Run `./revendor.sh`
- 3. Verify update was successful. `glide.lock` will have been updated to reflect the changes to `glide.yaml` and the package will have been updated in `vendor`.
+Adding new or updating existing backend dependencies:
+ 1. Edit the `go.mod` file to the desired version (most likely a git hash)
+ 2. Run `go mod tidy && go mod vendor`
+ 3. Verify update was successful. `go.sum` will have been updated to reflect the changes to `go.mod` and the package will have been updated in `vendor`.
 
 #### Frontend
 

STYLEGUIDE.md

@@ -1,4 +1,4 @@
-# Tectonic Console Styleguide
+# OpenShift Console Styleguide
 
 ## Directory and File Names
 
@@ -22,8 +22,12 @@
 - All SCSS variables should be scoped within their component.
 - We use [BEM](http://getbem.com) naming conventions.
 
-## JavaScript
+## TypeScript and JavaScript
 
+- New code should be written in TypeScript, not JavaScript.
+- Prefer functional components to class-based components.
+- Use [React hooks](https://reactjs.org/docs/hooks-intro.html) with functional components if you need state.
+- Prefer [composition to inheritance](https://reactjs.org/docs/composition-vs-inheritance.html).
 - Run the linter and follow all rules defined in .eslintrc
 - Never use absolute paths in code. The app should be able to run behind a proxy under an arbitrary path.
 - TESTS: Should follow a similar "test tables" convention as used in Go where applicable.

build-backend.sh

@@ -7,7 +7,7 @@ set -e
 
 PROJECT_DIR=$(basename ${PWD})
 
-GIT_TAG=`git describe --always --tags HEAD`
-LD_FLAGS="-w -X github.com/openshift/console/version.Version=${GIT_TAG}"
+GIT_TAG=${SOURCE_GIT_TAG:-$(git describe --always --tags HEAD)}
+LD_FLAGS="-w -X github.com/openshift/console/pkg/version.Version=${GIT_TAG}"
 
 CGO_ENABLED=0 go build -ldflags "${LD_FLAGS}" -o bin/bridge github.com/openshift/console/cmd/bridge

builder-run.sh

@@ -11,7 +11,7 @@ set -e
 # Without env vars:
 #   ./builder-run.sh ./my-script --my-script-arg1 --my-script-arg2
 
-BUILDER_IMAGE="quay.io/coreos/tectonic-console-builder:v16"
+BUILDER_IMAGE="quay.io/coreos/tectonic-console-builder:v17"
 
 # forward whitelisted env variables to docker
 ENV_STR=""

clean-frontend.sh

@@ -1,4 +1,4 @@
 #!/usr/bin/env bash
 
-rm -rf frontend/node_modules
+find frontend -type d -name 'node_modules' -prune -exec rm -rf {} \;
 rm -rf frontend/public/dist