Skip to content

Latest commit

 

History

History
43 lines (40 loc) · 7.21 KB

DoD.asciidoc

File metadata and controls

43 lines (40 loc) · 7.21 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)

    • ❏ 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 assigned to you (should actually be done before you start your implementation).

    • ❏ 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 (including shellcheck) succeeded. If failed and you clicked on Details scroll up and search for log lines like Error: Failed running test #

    • ❏ 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 master 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 master 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 (indent with 2 spaces, no tabs, functions start with do prefix, variables are enclosed with curly braces, variables in functions are declared with local, etc.)

  • ❏ You have already added the issue implemented by your PR in CHANGELOG.asciidoc 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, 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» has been added to a a folder named «tool» in updater that receives response bodies from URLs, updates tool versions, and checks if download URLs work.

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

    • ❏ The tool can be installed automatically (during setup via settings) or via the commandlet call.

    • ❏ During the installation process (devon «tool» setup) reasonable progress and status information are displayed.

    • ❏ The tool is integrated in a way that complies with the multi-tenancy of the devonfw-ide. That is the tool will be installed locally only to the software folder inside the devonfw-ide installation (${DEVON_IDE_HOME}). There are very few tools as exception to this rule like docker (RancherDesktop). But by default every new tool should be installed locally. Otherwise already get in touch and clarify your design upfront before implementing.

    • ❏ The tool can even be configured in a way that complies with the multi-tenancy of the devonfw-ide. That is configuration files can be placed inside the devonfw-ide installation (${DEVON_IDE_HOME}) - typically inside the conf folder. Note: If a tool reads configuration files from the users home directory this is not given as two installations of devonfw-ide using the same tool then would read the same config so one installation would influence the other.

    • ❏ The new commandlet is documented as «tool».asciidoc in the documentation folder.

    • ❏ The new commandlet is added and linked in cli.asciidoc.

    • ❏ The new commandlet is added and linked in scripts.asciidoc.

    • ❏ The new commandlet is included to devonfw-ide-usage.asciidoc.

    • ❏ The links and includes (see above) have to be added in alphabetical order.

    • ❏ 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 is a command-wrapper for «tool».

    • ❏ The new commandlet installs potential dependencies automatically (e.g. doDevonCommand «required-other-tool» setup silent).

    • ❏ The new commandlet defines the variable TOOL_VERSION_COMMAND before sourcing the functions. If no version check is supported by the tool itself set the value to -. In case your commandlet is not about a tool that can be setup, simply set the value as empty to make this explicit.

    • ❏ If the new commandlet is about a tool that can be setup, then test that also devon «tool» version list, devon «tool» version get, and devon «tool» version set are all working.

    • ❏ The variable «TOOL»_VERSION is honored by your commandlet so if present that version will be downloaded and installed.

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

  • ❏ In case your PR adds, changes, or removes a function (in functions or environment-project) you need to update functions.asciidoc accordingly. There is an automated test that will fail otherwise.