Giter Club home page Giter Club logo

demo-console-dev's Introduction

What is the problem challenge?

Take a look at the normal console image -- any source maps? any component names? any trace data?

(Use the crc console to demonstrate)

When working with dynamic console plugins, it can be frustratingly difficult to run console with a dev build to see what is going on inside console. So....

How can I run console with a dev build that loads my plugin(s)?

Attempt 1 - build and run console in the "normal" style...

  1. clone the repo ๐Ÿ‘‰ git clone https://github.com/openshift/console.git
  2. checkout the branch for the version I want to use ๐Ÿ‘‰ cd console; git checkout -b _4.12 -t origin/release-4.12
  3. run ./build.sh
  4. fail horribly
  5. install a bunch of requirements on my workstation (yuck, but golang is ok, especially for working with operators)
  6. try the build again
  7. watch the frontend build fail horribly
  8. read up (again) on webpack 4, legacy openssl, bad crypto hash algos, upgrading to webpack 5, tweaking package.json files in console to do things "right", realizing that not even Vojtech has this nut cracked, give up and go get a stiff bourbon some more coffee

But ... oh wait ... the dev setup for my plugin has console running in a off-cluster container. Maybe there is something there!

Attempt 2 - try using console's Dockerfiles to build a dev mode container image...

  1. go back to my repo clone
  2. git reset --hard origin/release=4.12 (or similar)
  3. which Dockerfile looks ok? ๐Ÿ‘‰ this one looks promising
  4. lets try the base Dockerfile, the images used should be setup for good builds:
podman build -t localhost/console:test -f Dockerfile .
  1. watch the container build fail because the base images are not available
  2. message people in "the know" and get pointed at how to maybe somehow get podman to have a access token to the openshift ci registry (Tal even has a document about how to do this, but it is still painful)
  3. try that a few times but then realize it'll probably break all other repos I've been using, and I don't feel like dealing with that
  4. give up and go get a stiff bourbon some more coffee

It is a huge annoyance to try to use images out of openshift ci repos! Like, huge.

But ... oh wait ... maybe it would be easy to adapt the existing Dockerfile to my own and use public images!?

Attempt 3 - adapt one of console's Dockerfiles to build my own local container with dev mode console...

  1. Humm, let's start with the base Dockerfile and try to work from there this one looks promising
  2. Humm, swapping to UBI containers could work ๐Ÿ‘‰ registry of UBI containers
  3. Humm, directly cloning the repo in the Dockerfile could work
  4. Look at the console builder image Dockerfile for some clues on versions of things needed ๐Ÿ‘‰ Dockerfile.builder
  5. Humm, the build works ok that way, but....
  6. Now we need the frontend to build dev instead of prod
  7. Right, do it old school downstream like ... apply patches! ๐Ÿ‘‰ patches for branches
  8. 1 patch to do dev-once instead of build ๐Ÿ‘‰ patch for dev-once
  9. The container build runs, and dev-once runs, and I can use it just like any other console image! ๐Ÿ˜„
  10. Yuck...console log is overrun with i18n error messages, another patch to reduce those! ๐Ÿ‘‰ patch for i18n logging
  11. Looking good. A few refactors and testing against various branches and it all looks to work

Why use patches instead of PR to console?

  • ...takes too long to get a PR reviewed and merged
  • ...patches can be added/removed/tuned as needed
  • ...even with a PR, would be be able to backport from master to 4.11? patches can

What now?

Now, we can create a dev build of console in a container locally and use it as if it is any other console image.

The advantages?

  • React dev tools now know the real names of all of the components! It's easy to see where console stops and plugins begin.

  • Source maps and debugging of console code is available! This makes it easy to trace app start up, plugin loading or even how extensions work.

  • Extra objects are available in window! Now we can look at a few new runtime data points.

demo-console-dev's People

Contributors

sjd78 avatar

Watchers

 avatar

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.