diff --git a/.github/ISSUE_TEMPLATE/config.yml b/.github/ISSUE_TEMPLATE/config.yml index 00769ec0d..e87427856 100644 --- a/.github/ISSUE_TEMPLATE/config.yml +++ b/.github/ISSUE_TEMPLATE/config.yml @@ -8,6 +8,12 @@ contact_links: - name: Support request url: https://forum.arduino.cc/ about: We can help you out on the Arduino Forum! + - name: Issue report guide + url: https://github.com/arduino/arduino-ide/blob/main/docs/issues.md#issue-report-guide + about: Learn about submitting issue reports to this repository. + - name: Contributor guide + url: https://github.com/arduino/arduino-ide/blob/main/docs/CONTRIBUTING.md#contributor-guide + about: Learn about contributing to this project. - name: Discuss development work on the project url: https://groups.google.com/a/arduino.cc/g/developers about: Arduino Developers Mailing List diff --git a/BUILDING.md b/BUILDING.md index b70bd0540..95c05f8f6 100644 --- a/BUILDING.md +++ b/BUILDING.md @@ -1,120 +1,3 @@ -# Development - -This page includes technical documentation for developers who want to build the IDE locally and contribute to the project. - -## Architecture overview - -The IDE consists of three major parts: - - the _Electron main_ process, - - the _backend_, and - - the _frontend_. - -The _Electron main_ process is responsible for: - - creating the application, - - managing the application lifecycle via listeners, and - - creating and managing the web pages for the app. - -In Electron, the process that runs the main entry JavaScript file is called the main process. The _Electron main_ process can display a GUI by creating web pages. An Electron app always has exactly one main process. - -By default, whenever the _Electron main_ process creates a web page, it will instantiate a new `BrowserWindow` instance. Since Electron uses Chromium for displaying web pages, Chromium's multi-process architecture is also used. Each web page in Electron runs in its own process, which is called the renderer process. Each `BrowserWindow` instance runs the web page in its own renderer process. When a `BrowserWindow` instance is destroyed, the corresponding renderer process is also terminated. The main process manages all web pages and their corresponding renderer processes. Each renderer process is isolated and only cares about the web page running in it.[[1]] - -In normal browsers, web pages usually run in a sandboxed environment, and accessing native resources are disallowed. However, Electron has the power to use Node.js APIs in the web pages allowing lower-level OS interactions. Due to security reasons, accessing native resources is an undesired behavior in the IDE. So by convention, we do not use Node.js APIs. (Note: the Node.js integration is [not yet disabled](https://github.com/eclipse-theia/theia/issues/2018) although it is not used). In the IDE, only the _backend_ allows OS interaction. - -The _backend_ process is responsible for: - - providing access to the filesystem, - - communicating with the [Arduino CLI](https://github.com/arduino/arduino-cli) via gRPC, - - running your terminal, - - exposing additional RESTful APIs, - - performing the Git commands in the local repositories, - - hosting and running any VS Code extensions, or - - executing VS Code tasks[[2]]. - -The _Electron main_ process spawns the _backend_ process. There is always exactly one _backend_ process. However, due to performance considerations, the _backend_ spawns several sub-processes for the filesystem watching, Git repository discovery, etc. The communication between the _backend_ process and its sub-processes is established via IPC. Besides spawning sub-processes, the _backend_ will start an HTTP server on a random available port, and serves the web application as static content. When the sub-processes are up and running, and the HTTP server is also listening, the _backend_ process sends the HTTP server port to the _Electron main_ process via IPC. The _Electron main_ process will load the _backend_'s endpoint in the `BrowserWindow`. - -The _frontend_ is running as an Electron renderer process and can invoke services implemented on the _backend_. The communication between the _backend_ and the _frontend_ is done via JSON-RPC over a websocket connection. This means, the services running in the _frontend_ are all proxies, and will ask the corresponding service implementation on the _backend_. - -[1]: https://www.electronjs.org/docs/tutorial/application-architecture#differences-between-main-process-and-renderer-process -[2]: https://code.visualstudio.com/Docs/editor/tasks - - -## Build from source - -If you’re familiar with TypeScript, the [Theia IDE](https://theia-ide.org/), and if you want to contribute to the -project, you should be able to build the Arduino IDE locally. -Please refer to the [Theia IDE prerequisites](https://github.com/eclipse-theia/theia/blob/master/doc/Developing.md#prerequisites) documentation for the setup instructions. -> **Note**: Node.js 14 must be used instead of the version 12 recommended at the link above. - -Once you have all the tools installed, you can build the editor following these steps - -1. Install the dependencies and build - ```sh - yarn - ``` - -2. Rebuild the dependencies - ```sh - yarn rebuild:browser - ``` - -3. Rebuild the electron dependencies - ```sh - yarn rebuild:electron - ``` - -4. Start the application - ```sh - yarn start - ``` - -### Notes for Windows contributors -Windows requires the Microsoft Visual C++ (MSVC) compiler toolset to be installed on your development machine. - -In case it's not already present, it can be downloaded from the "**Tools for Visual Studio 20XX**" section of the Visual Studio [downloads page](https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-studio-2022) via the "**Build Tools for Visual Studio 20XX**" (e.g., "**Build Tools for Visual Studio 2022**") download link. - -Select "**Desktop development with C++**" from the "**Workloads**" tab during the installation procedure. - -### CI - -This project is built on [GitHub Actions](https://github.com/arduino/arduino-ide/actions). - - - _Snapshot_ builds run when changes are pushed to the `main` branch, or when a PR is created against the `main` branch. For the sake of the review and verification process, the build artifacts for each operating system can be downloaded from the GitHub Actions page. - - _Nightly_ builds run every day at 03:00 GMT from the `main` branch. - - _Release_ builds run when a new tag is pushed to the remote. The tag must follow the [semver](https://semver.org/). For instance, `1.2.3` is a correct tag, but `v2.3.4` won't work. Steps to trigger a new release build: - - Create a local tag: - ```sh - git tag -a 1.2.3 -m "Creating a new tag for the `1.2.3` release." - ``` - - Push it to the remote: - ```sh - git push origin 1.2.3 - ``` - -## Notes for macOS contributors -Beginning in macOS 10.14.5, the software [must be notarized to run](https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution). The signing and notarization processes for the Arduino IDE are managed by our Continuous Integration (CI) workflows, implemented with GitHub Actions. On every push and pull request, the Arduino IDE is built and saved to a workflow artifact. These artifacts can be used by contributors and beta testers who don't want to set up a build system locally. -For security reasons, signing and notarization are disabled for workflow runs for pull requests from forks of this repository. This means that macOS will block you from running those artifacts. -Due to this limitation, Mac users have two options for testing contributions from forks: - -### The Safe approach (recommended) - -Follow [the instructions above](#build-from-source) to create the build environment locally, then build the code you want to test. - -### The Risky approach - -*Please note that this approach is risky as you are lowering the security on your system, therefore we strongly discourage you from following it.* -1. Use [this guide](https://help.apple.com/xcode/mac/10.2/index.html?localePath=en.lproj#/dev9b7736b0e), in order to disable Gatekeeper (at your own risk!). -1. Download the unsigned artifact provided by the CI workflow run related to the Pull Request at each push. -1. Re-enable Gatekeeper after tests are done, following the guide linked above. - -## FAQ - -* *Can I manually change the version of the [`arduino-cli`](https://github.com/arduino/arduino-cli/) used by the IDE?* - - Yes. It is possible but not recommended. The CLI exposes a set of functionality via [gRPC](https://github.com/arduino/arduino-cli/tree/master/rpc) and the IDE uses this API to communicate with the CLI. Before we build a new version of IDE, we pin a specific version of CLI and use the corresponding `proto` files to generate TypeScript modules for gRPC. This means, a particular version of IDE is compliant only with the pinned version of CLI. Mismatching IDE and CLI versions might not be able to communicate with each other. This could cause unpredictable IDE behavior. - -* *I have understood that not all versions of the CLI are compatible with my version of IDE but how can I manually update the `arduino-cli` inside the IDE?* - - [Get](https://arduino.github.io/arduino-cli/installation) the desired version of `arduino-cli` for your platform and manually replace the one inside the IDE. The CLI can be found inside the IDE at: - - Windows: `C:\path\to\Arduino IDE\resources\app\node_modules\arduino-ide-extension\build\arduino-cli.exe`, - - macOS: `/path/to/Arduino IDE.app/Contents/Resources/app/node_modules/arduino-ide-extension/build/arduino-cli`, and - - Linux: `/path/to/Arduino IDE/resources/app/node_modules/arduino-ide-extension/build/arduino-cli`. +# Development Guide +This documentation has been moved [**here**](docs/development.md#development-guide). diff --git a/README.md b/README.md index 324da2691..4297eea3d 100644 --- a/README.md +++ b/README.md @@ -20,10 +20,9 @@ If you need assistance, see the [Help Center](https://support.arduino.cc/hc/en-u ## Bugs & Issues -If you want to report an issue, you can submit it to the [issue tracker](https://github.com/arduino/arduino-ide/issues) of this repository. A few rules apply: +If you want to report an issue, you can submit it to the [issue tracker](https://github.com/arduino/arduino-ide/issues) of this repository. -- Before posting, please check if the same problem has been already reported by someone else to avoid duplicates. -- Remember to include as much detail as you can about your hardware set-up, code and steps for reproducing the issue. Make sure you're using an original Arduino board. +See [**the issue report guide**](docs/contributor-guide/issues.md#issue-report-guide) for instructions. ### Security @@ -35,16 +34,15 @@ e-mail contact: security@arduino.cc ## Contributions and development -Contributions are very welcome! You can browse the list of open issues to see what's needed and then you can submit your code using a Pull Request. Please provide detailed descriptions. We also appreciate any help in testing issues and patches contributed by other users. +Contributions are very welcome! There are several ways to participate in this project, including: -This repository contains the main code, but two more repositories are included during the build process: +- Fixing bugs +- Beta testing +- Translation -- [vscode-arduino-tools](https://github.com/arduino/vscode-arduino-tools): provides support for the language server and the debugger -- [arduino-language-server](https://github.com/arduino/arduino-language-server): provides the language server that parses Arduino code +See [**the contributor guide**](docs/CONTRIBUTING.md#contributor-guide) for more information. -See the [BUILDING.md](BUILDING.md) for a technical overview of the application and instructions for building the code. - -You can help with the translation of the Arduino IDE to your language here: [Arduino IDE on Transifex](https://www.transifex.com/arduino-1/ide2/dashboard/). +See the [**development guide**](docs/development.md) for a technical overview of the application and instructions for building the code. ## Donations diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md new file mode 100644 index 000000000..72e6a6e36 --- /dev/null +++ b/docs/CONTRIBUTING.md @@ -0,0 +1,29 @@ + + +# Contributor Guide + +Thanks for your interest in contributing to this project! + +There are several ways you can get involved: + +| Type of contribution | Contribution method | +| ----------------------------------------- | -------------------------------------------------------------------------------- | +| - Support
- Question
- Discussion | Post on the [**Arduino Forum**][forum] | +| - Bug report
- Feature request | Issue report (see the guide [**here**][issues]) | +| Testing | Beta testing, PR review (see the guide [**here**][beta-testing]) | +| Translation | [Transifex project][translate] | +| - Bug fix
- Enhancement | Pull request (see the guide [**here**][prs]) | +| Monetary | - [Donate][donate]
- [Sponsor][sponsor]
- [Buy official products][store] | + +[forum]: https://forum.arduino.cc +[issues]: contributor-guide/issues.md#issue-report-guide +[beta-testing]: contributor-guide/beta-testing.md#beta-testing-guide +[translate]: https://www.transifex.com/arduino-1/ide2/dashboard/ +[prs]: contributor-guide/pull-requests.md#pull-request-guide +[donate]: https://www.arduino.cc/en/donate/ +[sponsor]: https://github.com/sponsors/arduino +[store]: https://store.arduino.cc + +## Resources + +- [**Development Guide**](development.md#development-guide) diff --git a/docs/README.md b/docs/README.md index c5d9cf00f..6c6f59479 100644 --- a/docs/README.md +++ b/docs/README.md @@ -1,7 +1,7 @@ # Remote Sketchbook Arduino IDE provides a Remote Sketchbook feature that can be used to upload sketches to Arduino Cloud. -![](static/remote.png) +![](assets/remote.png) @@ -13,7 +13,7 @@ A developer could use the content of this repo to create a customized version of ### 1. Changing remote connection parameters in the Preferences panel (be careful while editing the Preferences panel!) Here a screenshot of the Preferences panel -![](static/preferences.png) +![](assets/preferences.png) - The settings under _Arduino > Auth_ should be edited to match the OAuth2 configuration of your custom remote sketchbook storage - The setting under _Arduino > Sketch Sync Endpoint_ should be edited to point to your custom remote sketchbook storage service ### 2. Implementing the Arduino Cloud Store APIs for your custom remote sketchbook storage diff --git a/docs/static/preferences.png b/docs/assets/preferences.png similarity index 100% rename from docs/static/preferences.png rename to docs/assets/preferences.png diff --git a/docs/static/remote.png b/docs/assets/remote.png similarity index 100% rename from docs/static/remote.png rename to docs/assets/remote.png diff --git a/docs/contributor-guide/assets/checks-tab.png b/docs/contributor-guide/assets/checks-tab.png new file mode 100644 index 000000000..ee1854952 Binary files /dev/null and b/docs/contributor-guide/assets/checks-tab.png differ diff --git a/docs/contributor-guide/assets/checks.png b/docs/contributor-guide/assets/checks.png new file mode 100644 index 000000000..888e711b4 Binary files /dev/null and b/docs/contributor-guide/assets/checks.png differ diff --git a/docs/contributor-guide/assets/tester-build-artifacts.png b/docs/contributor-guide/assets/tester-build-artifacts.png new file mode 100644 index 000000000..ab9dada84 Binary files /dev/null and b/docs/contributor-guide/assets/tester-build-artifacts.png differ diff --git a/docs/contributor-guide/assets/tester-build-link.png b/docs/contributor-guide/assets/tester-build-link.png new file mode 100644 index 000000000..136a47948 Binary files /dev/null and b/docs/contributor-guide/assets/tester-build-link.png differ diff --git a/docs/contributor-guide/beta-testing.md b/docs/contributor-guide/beta-testing.md new file mode 100644 index 000000000..487713f28 --- /dev/null +++ b/docs/contributor-guide/beta-testing.md @@ -0,0 +1,108 @@ + + +# Beta Testing Guide + +Beta testing of development versions is a valuable contribution to the project. You can help to ensure the quality of the production release that will be distributed to the user community. + +Builds of the project are automatically created after every relevant change to the project in order to make it easy for anyone to participate in the testing effort. + +--- + +❗ Make sure to always download the newest available tester build in order to ensure effective results from your beta testing efforts. + +--- + +Beta testing is done during both the proposal (pull request) and pre-release (nightly build) phases of development: + +## Testing Pull Requests + +Tester builds are automatically created for every [pull request](https://docs.github.com/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) (PR) that proposes a relevant change. + +The builds are updated if the author pushes changes to the PR. + +### Installation + +The tester build for a PR can be downloaded by following these instructions: + +1. Sign in to your [**GitHub**](https://github.com/) account.
+ (GitHub only allows downloads of the tester builds when you are signed in.) +1. Open the PR you are interested in.
+ They are listed here:
+ https://github.com/arduino/arduino-ide/pulls +1. Click the "**Checks**" tab at the top of the PR's page. +1. From the list on the left side of the page, click on "**Arduino IDE**". +1. Scroll down to the "**Artifacts**" section of the page that opens. +1. Click the download link for your operating system.
+ **ⓘ** For example, if you are using Windows, click the "**Windows_X86-64_zip**" link. +1. Wait for the download to finish. +1. Extract or install the downloaded file as usual. + +![checks tab](assets/checks-tab.png) + +![tester build link](assets/tester-build-link.png) + +![tester build artifacts](assets/tester-build-artifacts.png) + +#### Notes for macOS + +Beginning in macOS 10.14.5, the software [must be notarized to run](https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution). + +For security reasons, signing and notarization are disabled when creating tester builds for pull requests from forks of this repository. This means that macOS will block you from running the tester builds for those PRs. + +Due to this limitation, Mac users have two options for testing PRs from forks: + +##### The Safe Approach + +Build the version of the Arduino IDE you want to test from source instead of using the automatically created tester build. + +[Instructions for building the project](../development.md#build-from-source) + +##### The Risky Approach + +--- + +⚠ Please note that this approach is risky as you are lowering the security on your system, therefore we strongly discourage you from following it. + +--- + +1. Start the tester build.
+ A warning will appear: + > "Arduino IDE" cannot be opened because the developer cannot be verified. +1. Follow the instructions from the "**If you want to open an app that hasn't been notarized or is from an unidentified developer**" section of this page to bypass the security restriction:
+ [https://support.apple.com/en-us/HT202491](https://support.apple.com/en-us/HT202491#:~:text=If%20you%20want%20to%20open%20an%20app%20that%20hasn%E2%80%99t%20been%20notarized%20or%20is%20from%20an%20unidentified%20developer) + +### Feedback + +Feedback after beta testing a pull request is always valuable, regardless of which categories your findings fall under: + +- working as expected +- problems encountered +- areas for improvement + +Please submit feedback related to the changes made in the pull request as a PR review: + +https://docs.github.com/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews + +--- + +If you discover problems or areas for improvement that are unrelated to the changes made by the PR (i.e., they also occur when using the [nightly build](#testing-nightly-build)), please submit that feedback as an issue report instead of a review. + +[More information on issue reports](issues.md#issue-report-guide) + +## Testing Nightly Build + +Builds of the project's production branch are produced daily. This build represents the current pre-release state of the project, which is planned for distribution in the next release. + +### Installation + +1. Open Arduino's "**Software**" page:
+ https://www.arduino.cc/en/software#nightly-builds +1. Select the appropriate download link from the "**Nightly Builds**" section of the page. +1. Wait for the download to finish. +1. Extract or install the downloaded file as usual. + +### Feedback + +If you discover any problems or areas for improvement please submit an issue report. + +[More information on issue reports](issues.md#issue-report-guide) diff --git a/docs/contributor-guide/issues.md b/docs/contributor-guide/issues.md new file mode 100644 index 000000000..6fdb9ea8c --- /dev/null +++ b/docs/contributor-guide/issues.md @@ -0,0 +1,33 @@ + + +# Issue Report Guide + +--- + +❗ Do you need help or have a question about using this project? Support requests should be made to the [Arduino Forum](https://forum.arduino.cc). + +--- + +High quality bug reports and feature requests are valuable contributions to this project. These can be made by submitting an issue report to the project's GitHub repository: + +https://github.com/arduino/arduino-ide/issues/new/choose + +## Before Reporting an Issue + +- Give the latest development version a test drive to see if your issue was already resolved:
+ https://www.arduino.cc/en/software#nightly-builds +- Search [existing pull requests and issues](https://github.com/arduino/arduino-ide/issues?q=) to see if it was already reported.
+ If you have additional information to provide about an existing issue, please comment there instead of creating a duplicate. You can use [GitHub's "Reactions" feature](https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) if you only want to express support 👍. + +## Qualities of an Excellent Report + +- Concise and descriptive issue title.
+ Vague titles make it difficult to decipher the purpose of the issue when looking through the list of reports, which might result in your issue not being given proper attention. +- Describe the issue and what behavior you were expecting.
+ Include the full and exact text of any relevant error or warning messages you might have encountered. +- Provide a full set of steps necessary to reproduce the issue.
+ Demonstration code or commands should be complete and simplified to the minimum necessary to reproduce the issue. +- Be responsive.
+ We may need you to provide additional information in order to investigate and resolve the issue.
+ Make sure your GitHub account is configured so that you will receive notifications of responses to your issue report. +- If you find a solution to your problem, please comment on your issue report with an explanation of how you were able to fix it, then close the issue. diff --git a/docs/contributor-guide/pull-requests.md b/docs/contributor-guide/pull-requests.md new file mode 100644 index 000000000..6c3d29b23 --- /dev/null +++ b/docs/contributor-guide/pull-requests.md @@ -0,0 +1,199 @@ + + +# Pull Request Guide + +A [**pull request**](https://docs.github.com/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) (PR) is the mechanism used to propose changes to the content of this project's repository. + +If you are looking for ideas of what to work on, check [the list of open issue reports](https://github.com/arduino/arduino-ide/issues). Pull requests addressing any of those bug reports and feature requests are welcome. + +## Contribution Workflow + +Each contribution travels through a formal process which allows it to be efficiently incorporated into the project. + +### 1. Plan + +#### Research + +Start by searching the repository for existing pull requests and issues related to your planned contribution so you can see any related conversations and proposals and avoid duplicate effort: + +https://github.com/arduino/arduino-ide/issues?q= + +#### Discussion + +It can sometimes be useful to get feedback from others during the planning process. There are a couple good options for discussing planned development work: + +- Talk with the user community on the [Arduino Forum](https://forum.arduino.cc/). +- Talk with Arduino developers on the [Arduino Developers Mailing List](https://groups.google.com/a/arduino.cc/g/developers). + +### 2. Fork + +Forking a GitHub repository creates a copy of it under your account. You will stage contributions in your fork of this project. + +[More information about forking repositories](https://docs.github.com/get-started/quickstart/fork-a-repo) + +#### Enabling CI in Your Fork + +The repository is configured to run automated [continuous integration](https://wikipedia.org/wiki/Continuous_integration) (CI) checks and tests. It's a good idea to enable CI in your fork so you can make sure your work will pass the checks before you submit a pull request: + +1. Open the homepage of your fork in the browser. +1. Click the "**Actions**" tab. +1. Click the **I understand my workflows, go ahead and enable them** button. +1. Some of the workflows will now need to be activated individually. Perform the following steps for each of the useful workflows listed on the left side of the page that have a "**!**" icon: + 1. Click on the workflow name. + 1. Click the **Enable workflow** button. + +### 3. Clone + +Cloning a repository creates a copy of it on your computer. + +It is possible to make simple changes to your repository using the GitHub web interface without cloning the repository. However, the GitHub web interface is quite limiting so you will likely find the need to work with a clone (using **Git** directly or your choice of [Git client software](https://git-scm.com/downloads/guis)) for any significant development work. + +[More information about cloning repositories](https://git-scm.com/docs/git-clone) + +### 4. Branch + +Create a branch in your fork to contain the changes for your contribution. You must make a separate branch in your fork for each pull request you submit. + +[More information about branches](https://docs.github.com/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches) + +### 5. Make a change + +Some things to keep in mind: + +- Make sure your change complies with the project's established style conventions. +- Remember to also update the documentation content in the repository if required by your changes. +- If the project contains a test suite, update or add tests according to your change as appropriate. + +See [the development guide](../development.md#development-guide) for more information. + +### 6. Test + +Test your change carefully to make sure it works correctly and did not break other components of the project. + +As a supplement for general testing, the project is set up with automated checks and tests to facilitate development. + +See [the development guide](../development.md#development-guide) for instructions. + +### 7. Commit + +Once the work on your change is complete, add it to the revision history of the Git repository by making a commit. + +Make sure to follow the [Commit Guidelines](#commit-guidelines). + +[More information about commits](https://git-scm.com/docs/git-commit) + +### 8. Push + +If you're working from a [clone](#3-clone), you will need to push your commit to your fork on GitHub. + +[More information about pushing commits](https://git-scm.com/docs/git-push) + +#### Checking CI Results + +If you have [enabled CI in your repository](#enabling-ci-in-your-fork), GitHub will run the relevant checks automatically every time you push a commit to your fork. + +You can see the results of these checks by doing either of the following: + +- Clicking the status icon (✔️ or ❌) shown to the right of a commit. +- Opening the repository's "**Actions**" tab. + +### 9. Pull request + +A pull request (PR) is a proposal to make a change in a repository. The repository maintainer is able to accept the changes you propose in a pull request by simply clicking a button. + +[More information about pull requests](https://docs.github.com/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) + +#### Scope + +Each pull request should address a single bug fix or enhancement. If you have multiple unrelated fixes or enhancements to contribute, submit them as separate pull requests. + +#### Description + +Pull request title and description should follow [the same guidelines as commit messages](#commit-message). + +If your pull request fixes an issue in the issue tracker, use [a closing keyword](https://docs.github.com/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) in the body to indicate this. + +In some cases, it might make sense to request feedback on a proposal before it is ready to be merged. You can indicate this by starting the pull request title with **[WIP]** (work in progress). Once the pull request is ready to be merged, edit the title and remove the "[WIP]". + +#### Cross-repository Contributions + +Some proposals may require changes to multiple repositories. Pull requests should be submitted in parallel to each repository. + +Clearly note any dependencies on other PRs in the description so that these can be evaluated by the reviewer and the merges coordinated. + +--- + +Please check whether any changes are required to the related documentation content hosted in the separate dedicated repositories: + +- [**arduino/docs-content**](https://github.com/arduino/docs-content) +- [**arduino/help-center-content**](https://github.com/arduino/help-center-content) + +### 10. Resolve CI failures + +Relevant checks will run automatically once you have submitted the pull request. Once these checks are finished, you can see a summary of the results near the bottom of the pull request page: + +![checks](assets/checks.png) + +Failed checks will be indicated with an ❌. If any checks failed, please fix whatever caused it to fail. Click the "**Details**" link to the right of the check name to open the logs, which provide details about the failure. + +--- + +**ⓘ** In some rare cases, a CI failure may be unrelated to the changes made in your pull request. So if the information in the logs doesn't seem relevant, please comment on the pull request to ask a maintainer to take a look. + +--- + +When you push to the branch of your fork the pull request was submitted from, the commit is automatically added to the pull request. Don't create a new pull request to fix problems; update the existing pull request. + +### 11. Resolve changes requested from reviews + +Interested parties may review your pull request and suggest improvements. + +To act on general review suggestions, you can add commits to the branch you submitted the pull request from, which will automatically be added to the pull request. Don't create a new pull request to act on review suggestions; update the existing pull request. + +Reviewers may suggest specific changes, which can be applied by [clicking the **Commit suggestion** button](https://docs.github.com/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/incorporating-feedback-in-your-pull-request#applying-suggested-changes). + +[More information about pull request reviews](https://docs.github.com/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews) + +### 12. Merge + +One of the repository maintainers can now choose to accept your proposed change. Once the pull request is [merged](https://docs.github.com/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request), you can delete the branch you created in your fork for the pull request and delete the fork as well if you like. + +Thanks so much for your contribution! + +--- + +It is possible that the maintainers may decide a pull request doesn't align with Arduino's goals for the project and close it rather than merging. A record of the proposed changes will always be available on GitHub for future reference. If you think your modifications will be of use to others, you are welcome to maintain your own fork of the repository. + +--- + +## Commit Guidelines + +The commit history of a repository is an important resource for developers. Repositories may accumulate thousands of commits over the course of decades. Each individual commit contributes either to the commit history being pleasant and efficient to work with, or to it being a confusing mess. For this reason, it's essential for contributors to create clean, high quality commits. + +### Scope + +Commits must be "atomic". This means that the commit completely accomplishes a single task. Each commit should result in fully functional code. Multiple tasks should not be combined in a single commit, but a single task should not be split over multiple commits (e.g., one commit per file modified is not a good practice). + +[More information about atomic commits](https://www.freshconsulting.com/insights/blog/atomic-commits/) + +### Commit Message + +The commit message documents what the change was and why it was done. A little effort now writing a good commit message can save future developers from wasted time and frustration trying to understand the purpose of a poorly documented commit. + +#### Commit Message Title + +- Use the [imperative mood](https://cbea.ms/git-commit/#imperative) in the title.
+ For example: + > Use LED_BUILTIN macro in LED pin definition +- Capitalize the title. +- Do not end the title with punctuation. +- Do not use GitHub's default commit titles (e.g., "Update examples/Foo/Foo.ino"). + +#### Commit Message Body + +- Separate title from the body with a blank line. If you're committing via GitHub or [GitHub Desktop](https://desktop.github.com/) this will be done automatically. +- Wrap body at 120 characters. +- Completely explain the purpose of the commit.
+ Include a rationale for the change, any caveats, side-effects, etc. + +[More information on commit messages](https://cbea.ms/git-commit/) diff --git a/docs/development.md b/docs/development.md new file mode 100644 index 000000000..b3146acae --- /dev/null +++ b/docs/development.md @@ -0,0 +1,116 @@ +# Development Guide + +This page includes technical documentation for developers who want to build the IDE locally and contribute to the project. + +## Architecture overview + +The IDE consists of three major parts: + - the _Electron main_ process, + - the _backend_, and + - the _frontend_. + +The _Electron main_ process is responsible for: + - creating the application, + - managing the application lifecycle via listeners, and + - creating and managing the web pages for the app. + +In Electron, the process that runs the main entry JavaScript file is called the main process. The _Electron main_ process can display a GUI by creating web pages. An Electron app always has exactly one main process. + +By default, whenever the _Electron main_ process creates a web page, it will instantiate a new `BrowserWindow` instance. Since Electron uses Chromium for displaying web pages, Chromium's multi-process architecture is also used. Each web page in Electron runs in its own process, which is called the renderer process. Each `BrowserWindow` instance runs the web page in its own renderer process. When a `BrowserWindow` instance is destroyed, the corresponding renderer process is also terminated. The main process manages all web pages and their corresponding renderer processes. Each renderer process is isolated and only cares about the web page running in it.[[1]] + +In normal browsers, web pages usually run in a sandboxed environment, and accessing native resources are disallowed. However, Electron has the power to use Node.js APIs in the web pages allowing lower-level OS interactions. Due to security reasons, accessing native resources is an undesired behavior in the IDE. So by convention, we do not use Node.js APIs. (Note: the Node.js integration is [not yet disabled](https://github.com/eclipse-theia/theia/issues/2018) although it is not used). In the IDE, only the _backend_ allows OS interaction. + +The _backend_ process is responsible for: + - providing access to the filesystem, + - communicating with the [Arduino CLI](https://github.com/arduino/arduino-cli) via gRPC, + - running your terminal, + - exposing additional RESTful APIs, + - performing the Git commands in the local repositories, + - hosting and running any VS Code extensions, or + - executing VS Code tasks[[2]]. + +The _Electron main_ process spawns the _backend_ process. There is always exactly one _backend_ process. However, due to performance considerations, the _backend_ spawns several sub-processes for the filesystem watching, Git repository discovery, etc. The communication between the _backend_ process and its sub-processes is established via IPC. Besides spawning sub-processes, the _backend_ will start an HTTP server on a random available port, and serves the web application as static content. When the sub-processes are up and running, and the HTTP server is also listening, the _backend_ process sends the HTTP server port to the _Electron main_ process via IPC. The _Electron main_ process will load the _backend_'s endpoint in the `BrowserWindow`. + +The _frontend_ is running as an Electron renderer process and can invoke services implemented on the _backend_. The communication between the _backend_ and the _frontend_ is done via JSON-RPC over a websocket connection. This means, the services running in the _frontend_ are all proxies, and will ask the corresponding service implementation on the _backend_. + +[1]: https://www.electronjs.org/docs/tutorial/application-architecture#differences-between-main-process-and-renderer-process +[2]: https://code.visualstudio.com/Docs/editor/tasks + +### Additional Components + +This repository contains the main code, but two more repositories are included during the build process: + +- [vscode-arduino-tools](https://github.com/arduino/vscode-arduino-tools): provides support for the language server and the debugger +- [arduino-language-server](https://github.com/arduino/arduino-language-server): provides the language server that parses Arduino code + +## Build from source + +--- + +**ⓘ** If you only want to test an existing version of the project, automatically generated builds are available for download without building from source. See the instructions in the [**beta testing guide**](contributor-guide/beta-testing.md#beta-testing-guide). + +--- + +If you’re familiar with TypeScript, the [Theia IDE](https://theia-ide.org/), and if you want to contribute to the +project, you should be able to build the Arduino IDE locally. +Please refer to the [Theia IDE prerequisites](https://github.com/eclipse-theia/theia/blob/master/doc/Developing.md#prerequisites) documentation for the setup instructions. +> **Note**: Node.js 14 must be used instead of the version 12 recommended at the link above. + +Once you have all the tools installed, you can build the editor following these steps + +1. Install the dependencies and build + ```sh + yarn + ``` + +2. Rebuild the dependencies + ```sh + yarn rebuild:browser + ``` + +3. Rebuild the electron dependencies + ```sh + yarn rebuild:electron + ``` + +4. Start the application + ```sh + yarn start + ``` + +### Notes for Windows contributors +Windows requires the Microsoft Visual C++ (MSVC) compiler toolset to be installed on your development machine. + +In case it's not already present, it can be downloaded from the "**Tools for Visual Studio 20XX**" section of the Visual Studio [downloads page](https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-studio-2022) via the "**Build Tools for Visual Studio 20XX**" (e.g., "**Build Tools for Visual Studio 2022**") download link. + +Select "**Desktop development with C++**" from the "**Workloads**" tab during the installation procedure. + +### CI + +This project is built on [GitHub Actions](https://github.com/arduino/arduino-ide/actions). + + - _Snapshot_ builds run when changes are pushed to the `main` branch, or when a PR is created against the `main` branch. For the sake of the review and verification process, the build artifacts for each operating system can be downloaded from the GitHub Actions page. + - _Nightly_ builds run every day at 03:00 GMT from the `main` branch. + - _Release_ builds run when a new tag is pushed to the remote. The tag must follow the [semver](https://semver.org/). For instance, `1.2.3` is a correct tag, but `v2.3.4` won't work. Steps to trigger a new release build: + - Create a local tag: + ```sh + git tag -a 1.2.3 -m "Creating a new tag for the `1.2.3` release." + ``` + - Push it to the remote: + ```sh + git push origin 1.2.3 + ``` + +## FAQ + +* *Can I manually change the version of the [`arduino-cli`](https://github.com/arduino/arduino-cli/) used by the IDE?* + + Yes. It is possible but not recommended. The CLI exposes a set of functionality via [gRPC](https://github.com/arduino/arduino-cli/tree/master/rpc) and the IDE uses this API to communicate with the CLI. Before we build a new version of IDE, we pin a specific version of CLI and use the corresponding `proto` files to generate TypeScript modules for gRPC. This means, a particular version of IDE is compliant only with the pinned version of CLI. Mismatching IDE and CLI versions might not be able to communicate with each other. This could cause unpredictable IDE behavior. + +* *I have understood that not all versions of the CLI are compatible with my version of IDE but how can I manually update the `arduino-cli` inside the IDE?* + + [Get](https://arduino.github.io/arduino-cli/installation) the desired version of `arduino-cli` for your platform and manually replace the one inside the IDE. The CLI can be found inside the IDE at: + - Windows: `C:\path\to\Arduino IDE\resources\app\node_modules\arduino-ide-extension\build\arduino-cli.exe`, + - macOS: `/path/to/Arduino IDE.app/Contents/Resources/app/node_modules/arduino-ide-extension/build/arduino-cli`, and + - Linux: `/path/to/Arduino IDE/resources/app/node_modules/arduino-ide-extension/build/arduino-cli`. + diff --git a/docs/internal/Arm.md b/docs/internal/Arm.md index 8bcca9db4..f6f1d52aa 100644 --- a/docs/internal/Arm.md +++ b/docs/internal/Arm.md @@ -41,7 +41,7 @@ Building the Pro IDE on Linux `armv7l` (aka `armhf`) and `aarch64` (aka `arm64`) - `libx11-dev`, and - `libxkbfile-dev` -4. [Build it](../../BUILDING.md#build-from-source) from the source: +4. [Build it](../development.md#build-from-source) from the source: ``` git clone https://github.com/arduino/arduino-ide.git \ && cd arduino-ide \