Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@ This document outlines some of the conventions on development workflow.

This is a rough outline of what a contributor's workflow looks like:

- Create a topic branch from where you want to base your work (usually master).
- Create a topic branch from where you want to base your work (usually main).
Comment thread
coderabbitai[bot] marked this conversation as resolved.
- Make commits of logical units.
- Make sure your commit messages are in the proper format (see below).
- Push your changes to a topic branch in your fork of the repository.
Expand Down Expand Up @@ -60,7 +60,7 @@ a link to the issue in the commit description to make it easy to get to the issu
### Backporting Fixes

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
`release-4.1`. Typically, bugs are fixed in the main branch first then
backported to the appropriate release branches. Fixes backported to previous
releases should have a Bugzilla bug for each version fixed.

Expand Down
14 changes: 7 additions & 7 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,13 +16,13 @@ The console is a more friendly `kubectl` in the form of a single page webapp. It
### Dependencies:

1. [node.js](https://nodejs.org/) >= 22 with [corepack](https://npmjs.com/package/corepack) enabled for [yarn berry](https://yarnpkg.com/)
2. [go](https://golang.org/) >= 1.25
3. [oc](https://mirror.openshift.com/pub/openshift-v4/clients/oc/latest/) or [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) and an OpenShift or Kubernetes cluster
4. [jq](https://stedolan.github.io/jq/download/) (for `contrib/environment.sh`)
2. [go](https://go.dev/) >= 1.25
3. [oc](https://mirror.openshift.com/pub/openshift-v4/clients/oc/latest/) or [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) and an OpenShift or Kubernetes cluster
4. [jq](https://stedolan.github.io/jq/download/) (used by scripts and tests; see [code usage](https://github.com/search?q=repo%3Aopenshift%2Fconsole+%2F+jq+%2F+-path%3A**%2F*.md+-path%3A**%2FDockerfile*&type=code))

### Build everything:

This project uses [Go modules](https://github.com/golang/go/wiki/Modules),
This project uses [Go modules](https://go.dev/wiki/Modules),
so you should clone the project outside of your `GOPATH`. To build both the
frontend and backend, run:

Expand All @@ -38,7 +38,7 @@ The following instructions assume you have an existing cluster you can connect
to. OpenShift 4.x clusters can be installed using the
[OpenShift Installer](https://mirror.openshift.com/pub/openshift-v4/clients/ocp/latest/). More information about installing OpenShift can be found at
<https://try.openshift.com/>.
You can also use [CodeReady Containers](https://github.com/code-ready/crc)
You can also use [CodeReady Containers](https://github.com/crc-org/crc)
Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot Apr 28, 2026

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🌐 Web query:

Is crc.dev the official documentation site for CodeReady Containers?

💡 Result:

No, crc.dev is not the official documentation site for CodeReady Containers. crc.dev hosts the documentation for CRC (CodeReady Containers), which is the open-source upstream project. CodeReady Containers was Red Hat's branded distribution of CRC, now rebranded to Red Hat OpenShift Local. The official Red Hat documentation for Red Hat OpenShift Local (successor to CodeReady Containers) is hosted on access.redhat.com, such as https://access.redhat.com/documentation/en-us/red_hat_openshift_local/2.5/html-single/getting_started_guide/index.

Citations:


🏁 Script executed:

#!/bin/bash
# Get the README.md file around line 41 to see the context
cat -n README.md | head -60

Repository: openshift/console

Length of output: 3232


Clarify the documentation target—crc.dev documents the upstream open-source CRC project, not Red Hat's CodeReady Containers product.

The link should point to Red Hat's official OpenShift Local documentation (the successor to CodeReady Containers), not the upstream CRC repository. For consistency with this being an official OpenShift Console repository and the product context, use the Red Hat documentation rather than either the GitHub repo or upstream project docs.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@README.md` at line 41, Replace the current CRC GitHub link and wording in
README.md that says "You can also use CodeReady Containers" to reference Red
Hat's official OpenShift Local documentation instead; update the text to mention
"Red Hat OpenShift Local" (or "Red Hat's OpenShift Local") and replace the URL
with https://access.redhat.com/documentation/en-us/red_hat_openshift_local/ so
the doc points to the official Red Hat product docs rather than the upstream crc
project.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

This is a valid point; however, as long as I understand OpenShift Local still relies on CRC under the hood (and the installation guide on developers.redhat.com is not publicly accessible, unlike the CRC one), what do you think, @Leo6Leo?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!

for local installs, or native Kubernetes clusters.

#### OpenShift (no authentication)
Expand Down Expand Up @@ -139,7 +139,7 @@ In order to update the `tectonic-console-builder` to a new version (e.g., v29),

#### CodeReady Containers

If you want to use CodeReady for local development, first make sure [it is set up](https://crc.dev/crc/#setting-up-codeready-containers_gsg), and the [OpenShift cluster is started](https://crc.dev/crc/#starting-the-virtual-machine_gsg).
If you want to use CodeReady for local development, first make sure [it is set up](https://crc.dev/docs/networking/#setting-up-on-a-remote-server), and the [OpenShift cluster is started](https://crc.dev/docs/getting-started/#creating-openshift-preset).

To login to the cluster's API server, you can use the following command:

Expand Down Expand Up @@ -309,7 +309,7 @@ When running in headless mode, Cypress will test using its integrated Electron b
#### How the Integration Tests Run in CI

The end-to-end tests run against pull requests using [ci-operator](https://github.com/openshift/ci-operator/).
The tests are defined in [this manifest](https://github.com/openshift/release/blob/master/ci-operator/jobs/openshift/console/openshift-console-master-presubmits.yaml)
The tests are defined in [this manifest](https://github.com/openshift/release/blob/main/ci-operator/jobs/openshift/console/openshift-console-main-presubmits.yaml)
in the [openshift/release](https://github.com/openshift/release) repo and were generated with [ci-operator-prowgen](https://github.com/openshift/ci-operator-prowgen).

CI runs the [test-prow-e2e.sh](test-prow-e2e.sh) script, which runs [frontend/integration-tests/test-cypress.sh](frontend/integration-tests/test-cypress.sh).
Expand Down
2 changes: 1 addition & 1 deletion STYLEGUIDE.md
Original file line number Diff line number Diff line change
Expand Up @@ -33,7 +33,7 @@
- Scope all classes with a recognizable prefix to avoid collisions with any imported CSS (this project uses `co-` by convention).
- Class names should be all lowercase and dash-separated.
- All SCSS variables should be scoped within their component.
- We use [BEM](http://getbem.com) naming conventions.
- We use [BEM](https://getbem.com/) naming conventions.

## TypeScript and JavaScript

Expand Down