Skip to content

Latest commit

 

History

History
47 lines (44 loc) · 5.59 KB

DoD.adoc

File metadata and controls

47 lines (44 loc) · 5.59 KB
Raw
Table of Contents

Definition of Done

Before a pull request (PR) for devonfw-ide is ready for review, this definition of done (DoD) should be satisfied. Please note that external contributors are not strictly required to address all of these points as we love to get contributions and do not want to scare people from contributing with too much constraints. However, chances to get your change merged quickly are higher if you address all the following points.

  • ❏ Your PR and the issue follows our best-practices:

    • ❏ PR title is of the form #«issue-id»: «brief summary» (e.g. #921: fixed setup.bat).

    • ❏ PR top-level comment summarizes what has been done and contains link to addressed issue(s).

    • ❏ PR is linked with the issue(s) that it implements and resolves (see sidebar, click on Development and enter issue ID) - to archive this add fixes #«issue-id» to your PR summary.

    • ❏ PR and issue(s) have suitable labels (OS-specific like windows, macOS, or linux as well as other aspects like commandlet, plugins, urls, or tool specific labels such as eclipse or java)

    • ❏ Issue is set to In Progress and assigned to you (should actually be done before you start your implementation). See also here.

    • ❏ Milestones are typically assigned by PO (Jörg) but have to be set before issues and PRs get closed. In case your issue is only addressed by a change in ide-mirrors/ide-urls or in ide-settings repository, please already assign the according milestone (switch to closed tab under Milestone).

  • ❏ All checks have passed. Otherwise if a check failed (red cross) you need to click the Details link, read the logs and fix the problem.

    • ❏ The build and all automated tests succeeded. If failed and you clicked on Details add read the logs to find the error.

    • ❏ The contributors license agreement (CLA) is signed by all contributors of the PR.

    • ❏ Git-Gardian did not report any security issue

  • ❏ The feature branch of the PR is up-to-date with the main branch. If you see This branch is out-of-date with the base branch in the PR click the Update branch button to fix (or manually merge with the main from upstream locally and push your changes). In case you see This branch has conflicts that must be resolved instead, you need to resolve conflicts. Very simple conficts may be resolved in the browser on github. But as a general recommendation you should resolve the conflicts locally with proper merge tool support and rerun tests before you push the merged changes.

  • ❏ You followed all coding conventions

  • ❏ You have already added the issue implemented by your PR in CHANGELOG.adoc to the next open release (see milestones or maven.config). If there is no issue for your PR consider creating it or directly link the PR itself. Please note that the CHANGELOG shall only reflect public changes relevant for end-users. So e.g. if we implement a story and then add another PR as bugfix or improvement to the same story before the bug was ever released, we do not need to document this in the CHANGELOG to avoid spam and confusion.

  • ❏ In case your PR adds a new tool «tool» as commandlet there are the following additional checks:

    • ❏ A new UrlUpdater named «tool»UrlUpdater has been added to the according «tool» package.

    • ❏ A new commandlet named «tool» has been added that allows to install and launch the given software.

    • ❏ The tool can be installed automatically (when creating a new project with ide create «project-name» via settings git repo), via ide install «tool» or via the commandlet call ide «tool» «args».

    • ❏ The tool is installed locally to $IDE_HOME/software (and $IDE_ROOT/_ide/software). There are very few tools as exception to this rule like Docker that extend GlobalToolCommandlet.

    • ❏ The tool can be configured locally inside $IDE_HOME/conf and not from a global location (e.g. in $HOME). Note: If a tool reads configuration files from the users home directory this is not given as two IDEasy projects using the same tool then would read the same config so one installation would influence the other.

    • ❏ The help page displays information about the commandlet and its properties (CLI parameters) explaining how to use it properly. There are no warnings logged in the help output (like Cound not find key 'cmd-gcviewer' in ResourceBundle nls.Ide.properties). Therefore add proper help texts for all supported languages here.

    • ❏ The new tool is added to the table of tools in LICENSE.asciidoc with its according licesne. If that license is not yet included, the full license text needs to be added.

    • ❏ The new commandlet installs potential dependencies automatically (e.g. getCommandlet(«DependentTool».class).install() in overridden install method).

    • ❏ The variables «TOOL»_VERSION and «TOOL»_EDITION are honored by your commandlet so if present that edition and version will be downloaded and installed (happens by default but important if you implement custom installation logic).

    • ❏ The new commandlet is tested on all plattforms it is availible for. Assuming you are using Windows, testing for Linux can be done with WSL or Virtual Box and for MacOS we have a virtual cloud instance.