Notice: This project has been replaced by insights-advisor-frontend.
Requirements
- Node.js & npm
- gulp (Installed via
sudo npm install gulp -g
) - bower (Installed via
sudo npm install bower -g
) - c++ compiler
dnf install redhat-rpm-config gcc-c++
- compass (Installed via
gem install compass
) - sass-css-importer (Installed via
gem install --pre sass-css-importer
) - breakpoint (Installed via
gem install breakpoint
) - insights-frontend-assets (https://github.com/RedHatInsights/insights-frontend-assets)
- insights-proxy (https://github.com/RedHatInsights/insights-proxy) or accessproxy (https://github.com/redhataccess/accessproxy)
Getting started
- Init the assets submodule
$ git submodule init && git submodule update
- Install NPM dependencies
$ npm install
- This may print some errors on optional dependencies. This is okay.
- Start the development server
$ gulp
- Or
$ gulp dev-stable
to do work on the stable mode application
- Run the Insights proxy
# docker run --net=host -e MODE=all/content -p1337:1337 -ti docker.io/iphands/insightsproxy
- Or install and use the accessproxy npm cli app
Once the node server and insights-proxy
are both running, you can access the UI at:
- http://prod.foo.redhat.com:1337/insights
- http://stage.foo.redhat.com:1337/insights
- http://qa.foo.redhat.com:1337/insights
- http://ci.foo.redhat.com:1337/insights
- http://prod.foo.redhat.com:1337/insightsbeta
- http://stage.foo.redhat.com:1337/insightsbeta
- http://qa.foo.redhat.com:1337/insightsbeta
- http://ci.foo.redhat.com:1337/insightsbeta
Once loaded, you can switch to your local API instance by going to /insightsbeta/config/dev and then picking the "local" API Root preset.
Branching
There are 3 branches that will automatically push code out:
- master pushes code to Beta CI then if smoke tests pass to Beta Prod
- stable-4.x pushes code to Stable CI
- production-stable pushes code to Stable Prod
All development branches should be prefixed with one of the following
- fixes/ (for simple non feature bug fixes)
- features/ (for normal work intended to go to master)
- stable/ (for patches intended to go to stable)
- test/ (misc stuff)
i.e.
[master]$ git checkout -b features/super_cool_feature
Localization
- If you are adding any new English text, please add the translate tag.
- Use rh_locale and locale_debug Cookies to test your changes. A newly added English text with a correct tag will appear as "[MISSING]: text" until a proper translation is added.
- Once you are happy with the changes, run
gulp pot
and check in the new pot file for translation.
Before contributing your changes get familiar with the way master and stable branches work (see diagram) and the release process.
Contributing your changes to master (/insightsbeta)
This is the primary vehicle for getting your changes to Insights frontend.
Every change should go to master (/insightsbeta)
.
Optionally, you may also want to apply your changes to stable-X.Y (/insights)
.
See the next section for instructions on how to do that.
- Fork the master branch into a new feature branch (name the branch features/XXXX)
- Add and commit your changes.
- Squash your commits to achieve reasonable level of granularity
- Push your branch (git push origin features/XXXX)
- Create a new pull request. Use your feature branch as the source branch and
master
as the target branch. Assign the merge request to someone for review.
Contributing your changes to stable-X.Y (/insights)
Make sure you submit a merge request for master first. There may be cases where a merge request for master is needed but these are rare.
- Fork the stable-X.Y branch into a new feature branch. Use a
-stable
suffix to distinguish this branch from the one for master. Name the branch features/XXXX-stable. - Add and commit your changes. You can use
git cherry-pick
to take specific commits from another branch and apply them. - Squash your commits to achieve reasonable level of granularity
- Push your branch (git push origin features/XXXX-stable)
- Create a new pull request. Use your feature branch as the source branch and
stable-X.Y
as the target branch. Assign the merge request to someone for review.
When submitting a trivial change (e.g. a simple typo fix) that applies cleanly to both master and stable-X.Y branches you can skips the steps described in this section. Instead, only send a merge request against the master branch (as described in "Contributing your changes to master (/insightsbeta)" section). In addition, use merge request label "stable" on the merge request. The label indicates to the reviewer that besides a merge to the master branch, they should also cherry-pick the change to the stable-X.Y branch. Use this shortcut only for simple changes after you verified that the change applies cleanly to both branches. Otherwise, the reviewer will likely reject your merge request.
Code for the Insights plugin for Satellite resides in the "satellite" branch.
Building For Satellite
git checkout satellite
- Make your code changes and commit them. Don't forget to update the version number in package.json
gulp sat
- Copy the built build/js/insights.unmin.js and build/css/sat6.css to the plugin project