Skip to content

Latest commit

 

History

History
182 lines (144 loc) · 10.8 KB

CONTRIBUTING.md

File metadata and controls

182 lines (144 loc) · 10.8 KB
Raw

Contributing to Trace Viewer extension

Thanks for your interest in the Trace Viewer extension! The following is a set of guidelines for contributing to the Trace Viewer extension for Theia applications.

How to Contribute

⚠️ Important note Setting up the development environment on Linux is the easiest. If you are trying to run the project on Windows or MacOs and you are encountering issues, please contact us.

In order to contribute, please first open an issue that clearly describes the bug you intend to fix or the feature you would like to add. Make sure you provide a way to reproduce the bug or test the proposed feature.

Once you have your code ready for review, please open a pull request. Please follow the pull request guidelines. If you are new to the project, the new contributors section provides useful information to get you started. A committer of the Trace Extension will then review your contribution and help to get it merged.

Code of Conduct

This project is governed by the Eclipse Community Code of Conduct. By participating, you are expected to uphold this code.

Eclipse Development Process

This Eclipse Foundation open project is governed by the Eclipse Foundation Development Process and operates under the terms of the Eclipse IP Policy.

Eclipse Contributor Agreement

In order to be able to contribute to Eclipse Foundation projects you must electronically sign the Eclipse Contributor Agreement (ECA).

The ECA provides the Eclipse Foundation with a permanent record that you agree that each of your contributions will comply with the commitments documented in the Developer Certificate of Origin (DCO). Having an ECA on file associated with the email address matching the "Author" field of your contribution's Git commits fulfills the DCO's requirement that you sign-off on your contributions.

For more information, please see the Eclipse Committer Handbook.

Pull request guidelines

Changes to the project are made by submitting code with a pull request (PR).

Good commit messages make it easier to review code and understand why the changes were made. Please include a:

  • Title: Concise and complete title written in imperative (e.g. "Update Gitpod demo screenshots" or "Single-click to select or open trace")
  • Problem: What is the situation that needs to be resolved? Why does the problem need fixing? Link to related issues (e.g. "Fixes #317").
  • Solution: What changes were made to resolve the situation? Why are these changes the right fix?
  • Impact: What impact do these changes have? (e.g. Numbers to show a performance improvement, screenshots or a video for a UI change)
  • Sign-off: Use your full name and a long-term email address. This certifies that you have written the code and that, from a licensing perspective, the code is appropriate for use in open-source.

Other commit information:

New contributors

Explore the project context

  • Check out the tracevizlabs. You don't need to complete all of them, but reading a couple is good for context. Lab sets 0 and 1 are especially useful.
  • Browse recent conference presentations. They give an overview of the trace viewer's goals, architecture, and functionality.
    • Trace Compass Cloud: Eclipse Trace Compass's migration towards Theia, slides, video - Bernd Hufmann, Ericsson AB (EclipseCon 2021)
    • Using Theia to take trace analysis and visualization to the next level, slides, video - Bernd Hufmann, Ericsson AB (EclipseCon 2019)
    • A New Flexible Architecture for Trace Compass, slides, video - Michel Dagenais, Polytechnique Montréal (Tracing Summit 2019)
  • Get an overview of external components used by this trace viewer. See how they interact.

Start with a small change

  • Explore the Gitpod demo. Experiment with the trace viewer. Start exploring its code via Gitpod's in-browser IDE.
  • Start with a small frontend improvement. A relevant change can be less than 5 lines of code. The Theia-based frontend repo is much less complex than the Trace Server's, so by starting in the frontend you'll learn high-level context about the project's different components without being overwhelmed with complexity.
    • Good first issues
    • Develop with Gitpod to initially avoid dev setup. Put gitpod.io/# before your project fork's GitHub URL to open an in-browser IDE and initially avoid any local dev setup. This dev approach works best for small changes because Gitpod workspaces are volatile.
    • Learn how to contribute code. Starting with a tiny change means you can first focus on exploring the code as well as learning the submission and review process (which is a significant learning step if you've never submitted a PR before).

Uplifting the Theia dependencies version

Should one be willing to contribute such an uplift, these are the steps to consider, while more may be necessary depending on the case. Here is an example used to uplift from version 1.34.1 to 1.34.2:

  1. cd theia or go to the Theia repository using a local terminal.
  2. git fetch && git tag can be used to explore the latest released version tags.
  3. git diff v1.34.1-community v1.34.2 CHANGELOG.md (e.g.).
    • To assess if any change may break the extension.
    • If any breaking change, then consider it before uplifting; then, continue.
  4. git diff v1.34.1-community v1.34.2 (adding --name-only first if need be).
    • To assess if any noteworthy dependency versions were bumped since the previous uplift.
    • Some bumps may then be required also in the extension; consider applying them.
  5. Uplift the version of each @theia/ dependency in these package.json files, from 1.34.1 to 1.34.2 (replacing the former with the latter):
    • ./examples/browser/package.json
    • ./examples/docker/example-package.json
    • ./examples/electron/package.json
    • ./package.json
    • ./theia-extensions/viewer-prototype/package.json
  6. Align these React dependency versions in ./package.json with Theia's packages/core/package.json, when applicable:
    • "react"
    • "react-dom"
    • "@types/react"
    • "@types/react-dom"
  7. Do the same also for react-test-renderer in packages/react-components/package.json, and potentially elsewhere in the extension.
  8. Align node-version in .github/workflows yaml files with Theia's.
    • Referring also to Theia's "node" and @types/node versions in its root package.json file.

Formatting code with Prettier

If a commit fails to pass CI checks because of its format, contributors can use Prettier, which is already conveniently set up in the project, to quickly format their commit.

  • To format a single file, simply run yarn prettier --write <path-to-file>.
  • To run Prettier on all source code files, run yarn format:write. Prettier will only format files that are not formatted correctly.
  • To check if new changes comply with Prettier rules, run yarn prettier --check <path-to-file> or yarn format:check to perform the check on a single file or all source code file, respectively.

Ignoring linting/formatting commits

Should one be needing to use git blame to view the changes that were made recently to a file, it might be necessary to ignore the changes that were made in linting/formatting commits. In the root of the repo, there is a .git-blame-ignore-revs file. Adding the SHA-1 of a commit to this file will make git-blame ignore that commit. To use this file:

  • For GitHub, this file is automatically detected and will ignore all the commits that are included in the file.
  • With Git CLI, run git blame --ignore-revs-file=.git-blame-ignore-revs <pathToSomeFile> to ignore the commits.

Contact

For issues related to the Trace Viewer, please open a GitHub tracker for the Theia Trace Extension.

For issues concerning eclipse-cdt-cloud, please refer to the contact options listed on the CDT.Cloud website.