- [Microsoft Visual C++ Redistributable](https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170#visual-studio-2015-2017-2019-and-2022)
Depending on to what part of project you contribute to, you can specify to run tests for the given module only, ie., if you are working on extensions, you can run the tests for extensions and have faster feedback:
In case of adding new feature, it is always suitable to make sure we do not bring any new regression. For this purpose we are using the E2E tests. They can be built and run using `pnpm` with a variety of options:
You can find more specific options on the [package.json](https://github.com/podman-desktop/podman-desktop/blob/main/package.json) file, under 'scripts'.
- If you want to execute the tests outside of the repository, you can find a setup guide in this [README](https://github.com/podman-desktop/podman-desktop/tree/main/tests/playwright#podman-desktop-playwright-tests).
In case of an error, you can find more information that can help you debug in the `podman-desktop/tests/playwright/output` folder. You have the video repetitions on `videos`, captures of the application failing the test on `screenshots`, and the traces of the execution on `traces`. The latter ones can be opened with `npx playwright show-trace <path/to/trace/zip`.
Part of every test is also a code coverage report which can be obtain from the test run output (using simple text reporter)
found in project root `./test-resources/coverage/*`. Depending if you have run all or just a part of the tests, you will have partial test coverage report generated, example:
> **_NOTE:_** macOS and Windows create binaries while Linux will create a `.flatpak`. Make sure your flatpak dependencies are installed for successful compiling on Linux.
> **_macOS NOTE:_** On macOS the `dist/` folder will contain folders for `arm64` and `universal` `.app` files. Ignore these and use the `.app` file in the `dist/mac/` folder for testing.
> **_macOS CODE SIGNING:_** When testing the compiled binary on macOS, you must ad-hoc sign the application before launching it. Without signing, macOS will terminate the app with a `Code Signature Invalid` error. Run the following command after compiling:
We typically require one approval for code as well as documentation-related PR's. If it is a large code-related PR, proof of review / testing (a video / screenshot) is required.
**Avoid enabling auto-merge** until the PR has undergone sufficient reviews and contributors have been given ample time for assessment. A maintainer will review the PR prior to the final merge. It's common for code PRs to require up to a week before merging due to reasons such as ongoing releases or dependencies on other PRs. Additionally, documentation PRs might take a few days for integration.
### Skipping Jobs for Draft Pull Requests on GitHub
When creating a pull request in **draft mode** on GitHub, all CI/CD jobs are **skipped by default**. This behavior is intentional to avoid triggering unnecessary workflows while the pull request is still in progress.
#### Triggering Jobs in Draft Mode
If you want to run jobs for a pull request in **draft mode**, you need to manually apply the `area/ci` label to the pull request. Applying this label signals the CI system to execute the associated workflows, even though the pull request remains in draft.
#### Steps to Trigger Jobs in Draft Mode
1. Open your pull request in draft mode.
2. Navigate to the **Labels** section in the right-hand sidebar.
3. Apply the `area/ci` label.
This action will trigger the configured CI/CD workflows for your draft pull request.
#### Example Scenario
- **Without the `area/ci` label**: No jobs will run for your draft pull request.
- **With the `area/ci` label**: Jobs will be triggered, allowing you to validate your work in progress.
This ensures that CI resources are used efficiently while still providing flexibility for testing during the draft stage.
-`buildResources`: Podman Desktop logo location / build resources for electron
-`extensions`: We separate functionality into separate "extensions" to keep Podman Desktop modular. Here you'll find extensions such as Kubernetes, CRC, Podman and Docker functionality that Podman Desktop interacts with and integrates into the API (see `packages/extension-api`). Examples include `extensions/crc`, `extensions/podman`, `extensions/docker`.
-`packages/extension-api`: The extension API for extensions such as `extensions/podman` to interact with the Podman Desktop GUI. This API acts as a "middleware" to the main Electron functionality such as displaying notifications, progress messages, configuration changes, etc.
-`packages/main`: Electron process code that is responsible for creating the app's main windows, setting up system events and communicating with other processes
-`packages/preload`: Electron code that runs before the page gets rendered. Typically has access to APIs and used to setup communication processes between the main and renderer code.
-`packages/preload-docker-extension`: Electron preload code specific to the Docker Desktop extension.
-`packages/renderer`: Electron code that runs in the renderer process. The renderer runs separate to the main process and is responsible for typically rendering the main pages of Podman Desktop. Typically, this is where you find the `.svelte` code that renders the main Podman Desktop UI.
> **_NOTE:_** Each `extension` folder is a separately packaged module. If there are any issues with loading, make sure your module is packaged correctly.
Colors in Podman Desktop are now managed by a [`color-registry.ts`](https://github.com/podman-desktop/podman-desktop/blob/main/packages/main/src/plugin/color-registry.ts) file in order to easily switch between light and dark mode.
When contributing a UI component to Podman Desktop that is colorized, you must go through some steps to figure out what color to use and how to reference it.
1. Choose what UI component you want to add: Ex. I want to add a new primary button.
2. Look under `initColors()` and pick `this.initButton()` and scroll down to `protected initButton()`.
3. Pick a color. I want to use the the "primary" button. So I will pick: `${button}primary-bg`.
4. Scroll up and note the `const` below `protected initButton()` which is `const button = 'button-';`
5. The color can be referenced with `[var(--pd-button-primary-bg)]`. The `[var(--pd-` portion will always be consistent when refering to a color variable.
- Review the [status/need-triage](https://github.com/podman-desktop/podman-desktop/issues?q=is%3Aopen+is%3Aissue+label%3Astatus%2Fneed-triage) label on new issues. As a maintainer, you will need to categorize these issues under the correct [domain labels](https://github.com/podman-desktop/podman-desktop/labels?q=domain%2F).
- Validate the issue type. Since issues can be opened without templates or may not align with the chosen template, ensure the issue is correctly classified and update labels accordingly. For example, an issue opened as a bug may actually be a feature request and should be relabeled to reflect the correct type.
- Add `dev/investigate` label if there is a need for the engineering team to take an initial look and provide some info on where the changes could be and categorize the issue in appropriate area. Add the issue to the current sprint.
- Add `qe/review` label if we want QE to reproduce this issue.
- Add `status/info-needed` label if logs are missing or additional info is needed from the user filing the issue
- Identify issues that are simple to resolve and marking them as "good first issue," thereby encouraging newcomers to contribute to the project.
- Once categorized, remove the `status/need-triage` label.
- Evaluate the severity of new issues. If an issue is classified as "critical" or "high priority" and requires immediate attention, tag a maintainer in the issue and notify them via the public community channel.
- Evaluate any stale / lingering pull requests and pinging the respective contributors. If the pull request has been opened for an extensive amount of time, ping someone to contact the contributor / push any changes required to get it merged in. If there is no communication / the pull request is stale, close them.
