Contributors Guide - ni/labview-icon-editor GitHub Wiki

  1. Introduction
  2. Contribution requirements
  3. Contribution process
  4. Review process
  5. Contribution practical examples

Introduction

In progress

Contribution requirements

A signed Contributors License Agreement is necessary in order to accept pull requests from contributors. See the following link on information on Contributors License Agreements. NI will reach out to individual contributors when they submit a pull request.

Contribution process

Steps below outline the step-by- step process to contribute to the icon editor.

1 - Get assigned to the feature or bugfix you want to work on

We need to assign contributors to issues, because assigning someone to an issue triggers a GitHub action that creates the feature branch.

Look for an issue labeled as Workflow: Open to contribution and comment on the issue for you to be assigned to it.

Multiple people can be assigned to the same GitHub issue, and we will accept pull requests on the order we receive them.

Having a feature branch available and getting assigned to the Github Issue is the first gate into getting your code submission into the shipping version of the Icon Editor for next LabVIEW release.

2 - Bring the feature branch from upstream to origin

Upstream refers to the original repo, and origin refers to your personal copy of the repo or fork. See the following link with additional information about the difference between upstream and origin.

2.1 - Add upstream (only execute if you havent added the upstream yet)

Copy and paste the following git command on your git terminal.

git remote add upstream https://github.com/ni/labview-icon-editor
git fetch upstream

2.2 - Checkout feature branch

Checkout the feature branch for the GitHub issue you selected.

2.3 - Push feature branch to origin

On your git client, right click the feature branch, and select "push feature-branch to origin"

2.4 - Create a new branch from feature branch

While you have the feature branch from your fork checked out, create a new branch. Add a suffix with your name on it. (e.g. if feature branch is origin/feature/12-cleanup-actor-vi, and your name is Robert, then your branch would be origin/feature/12-cleanup-actor-vi-robert)

3 - Build baseline VI Package

In order to help us ensure quality, we have standardized the way we build and test the icon editor via a Powershell script.

First step before modifying the icon editor source, is to ensure that your build tools work, since those same tools are the ones that will run on the build agent.
See a video on how to do it from scratch following the process described below

Installation and verification process

Follow these steps to ensure your system is ready to edit the source.

Step 1: Apply dependencies

  • Open VIPM, switch to 2021 32-bit and apply \Tooling\deployment\dependencies.vipc
  • Switch VIPM to LabVIEW 2021 64-bit and apply the VIPC again

Step 2: Disable security warnings for "Run When Opened" VIs

The alternative to this step is to wait for the popup to occurr, and acknowledge it, this way it gets added to the list of "allowed" VIs. Although this would require you to manually acknowledge the process initially for the VIs to be added to the AllowedList.

In order to disable the warning, enable the following option on both 32 and 64-bit LV2021:

Tools/Options/Security/Run VI without warning

Step 3: Open latest pwsh (Powershell) in admin mode, and navigate to

\labview-icon-editor\pipeline\scripts\

Step 4: Copy the following command into Powershell:

.\Build.ps1 -RelativePath "C:\labview-icon-editor" -AbsolutePathScripts "C:\labview-icon-editor\pipeline\scripts"

Note: Before pressing enter, make sure that you closed LabVIEW and VI Package manager.

A VI package will be created on the builds folder

Step 5: Run the script that enables you to edit the source

.\Set_Development_Mode.ps1 -RelativePath "C:\labview-icon-editor"

4 - Finish the feature

Having finished the previous steps, you now know you are working from a known good system that can distribute a copy of your version of the icon editor. Once you are finished with your feature, run the build script again in and install the VI package to test your change.

5 - Submit a pull request

Create a pull request, and select the template that best fits your case.

6 - Pull request review process

The review process has 2 parts or "gates". The first gate is the "Feature Gate", which runs only the unit tests that were available at the time that the feature branch was created, plus any new unit tests that want to be introduced.

The second gate is the "Develop Gate", which will run the latest unit tests from the develop branch plus any new unit tests that you may have introduced.

All tasks from below are made on NI infrastructure when you submit a pull request:

6.1 - Feature Gate

The feature gate is the gate that your pull request would need to pass to be merged into NIs feature branch.

6.1.0 - Check #1 : Signed CLA

Ensures that the contributor(s) have a signed CLA. If not, NI will reach out to have this sorted out in order to continue to the next gate.

6.1.1 - Check #2 - : Run current unit tests

Runs a series of PowerShell scripts using G-CLI that execute the unit tests contained on the unit tests folder. If you have a unit test you want to add, add it to this folder. Note: If someone else introduced a unit test into develop, this unit test will not be executed at this check.

6.1.2 - Check #3 : Build current PPLs

Runs a series of PowerShell scripts using G-CLI that applies the VIPC, set the LabVIEW token, and build the ppls. This for both 32 and 64 bit versions.

6.1.3 - Check #4 : Build VI Package

Runs a series of PowerShell scripts using G-CLI that builds a VI Package

6.1.4 - Check #5 : First reviewer

Once check #4 is completed, an approver will be assigned by NI. After resolving any review comments from the NI-assigned approver, this check will be considered passed, and this would move you to the develop gate.

6.2 Develop Gate

The difference between this gate and the feature gate, is that this gate may have unit tests from other contributors that have not been executed on the code from this pull request.

If any of the new unit tests fail, your pull request will be stopped at this gate. In order to avoid this, it is recommended to synch your fork so you have the latest unit tests from develop, merge develop into your feature branch, and running the unit tests locally before submitting a pull request. This is considered to be an edge case, but it can happen.

6.2.0 - Check #6 : Run latest unit tests

Runs a series of PowerShell scripts using G-CLI that execute the unit tests contained on the unit tests folder.

6.2.1 - Check #7 : Build latest PPLs

Runs a series of PowerShell scripts using G-CLI that applies the VIPC, set the LabVIEW token, and build the ppl. This for both 32 and 64 bit versions of LabVIEW 2021.

6.2.2 - Check #8 : Build VI Package

Runs a series of PowerShell scripts using G-CLI that builds a VI Package

6.2.3 - Check #9 : Second reviewer

Once check #8 is completed, an approver will be assigned by NI. After resolving any review comments from the NI-assigned approver, this check will be considered passed, and NI will merge the code into develop.

After the code is merged by NI into develop, a VI Package is posted on the artifacts section with the new changes.

Contribution practical examples

in progress