Using the same process for all NI Open Source repos.

[svelderrainruiz]

@shivaprasad-basavaraj
@niACS

This GH discussion opens a conversation of using the same process for all NI Open Source repos:

Why?: This repo only has a main branch, which suggests that trunk-based development is planned to be used moving forward on this repo. This will create a precedent to use multiple branching models on a process that only supports 1, which i do not recommend without a strong reason. If there is a strong reason to deviate from GitFlow, we would benefit from having that documented on this discussion, since it would give steercos the reason to support multiple branching models and adapt the documentation to guide collaborators efficiently.

Sequential process if this repo uses the process we follow for ni/labview-icon-editor and ni/actor-framework:

1. NI Employee Creates a develop branch based on the latest main branch, and sets it as the default branch on the repo settings.
2. If NI approves me porting CI/CD to this repo (just via a simple comment on this discussion), I create an issue referencing this discussion that explains the work i will do as a volunteer.
3. Once the scope of work is clear on the GH Issue (or this discussion), an NI Employee assigns me to the issue and creates a feature branch (e.g. feature/[ssue nummber]-runner-ci-work)
4. I port a GitHub workflow from icon-editor to build the same VI Package that was commited to Builds/ni_lib_state_pattern_actor-2.0.0.16.vip‎. See this workflow run as an example on how i was able to build the AF core, which can be reused on this repo (if this repo follows GitFlow).
5. NI Employee configures a GH self-hosted runner on a VM with the label "state-pattern-actor" (i recommend reusing US-AUS-OSCI2 since it has LabVIEW 2020 installed)
6. I make a PR from my fork's feature branch into NI's feature branch, this will automatically build the state-pattern-actor VI Package using my runner.
7. If state-pattern-actor built on my fork's runner has no errors, NI Employee can merge the PR.
8. NI Employee makes a PR from the feature branch into the develop branch.
9. NI employee creates a release candidate branch (i normally use a git client like Fork for ease of use, where GitFlow can be initialized)
10. Release candidate branch will produce a new workflow run post the built artifact (.vip) as a pre-release that the LabVIEW community will be able to see on the main repo page, install, and report bugs to (now using NI's infrastructure to build it). Bugfixes go directly into the release candidate branch without having to go to develop.
11. Once the release candidate is tested, NI Employee uses a git client (like Fork) to finish the RC, this will merge into the main and backport to the develop branch, as well as tagging the release on main
12. Once the release is tagged on main, a workflow will automatically post the VI Package into a GH release. This removes the need to commit VI Packages to the repo.
13. Finally, this new workflow can be used as a required check on the repo settings for every PR made into feature branches or release candidate branches. This would start the cycle of a repo that gets built artifacts on PRs to feature branches (without a fork's owner having to setup a github self-hosted runner).

This ensures that the VI Package is built on a single location (NI's infrastructure), which creates a single point of failure/single point of debug.

If there is a bugfix we didn't discover on a release candidate, a hotfix branch can be used.

[niACS]

This repo only has a main branch because it is new, was created from a legacy library, and is very small. I believe I made a feature branch for the purpose of making my one recent fix, following the suggested process from the contributor perspective. Feel free to create a develop branch as appropriate.

[svelderrainruiz]

@shivaprasad-basavaraj can you please create a develop branch?

[shivaprasad-basavaraj]

@svelderrainruiz This was a new repo I had created to host the State Pattern Actor code and wasn't expecting it to be active and hence hadn't setup the repo fully. I have now created a develop branch and applied branch protections to mirror the actor-framework repo.

Regarding the CI/CD setup for this repo, we are discussing internally our plans for CI/CD for NI's open source repos and I will get back to you regarding this in a couple of weeks.