[
https://issues.apache.org/jira/browse/NIFI-14159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933229#comment-17933229
]
David Pfingst commented on NIFI-14159:
--------------------------------------
[~joewitt] Thank you very much for your reply and sorry for my very late
answer.
After thinking about it for a while I totally agree with you that states
shouldn't be versioned.
I'm now using the Nifi REST API in my CI/CD Gitlab Pipeline and it works very
well. New deployed process groups can be activated throught the pipeline in our
case.
But what I discovered after working with Nifi Version Control for a while that
versioned sub process groups lead into new issues:
When I use a versioned process group on the root canvas that contains other
versioned process groups there are many issues when I try to work with gitlab
branches.
Suppose I have a feature branch to work on new features in the sub process
group. I would load the parent process group into my local nifi to work on it.
But when I load a process group from the main branch then I would have to
delete the sub process group because it comes from the main branch that is
deployed. Then I would have to import the process group from the feature branch
to work on it. But when I commit changes and merge the branch into a release
and then into main branch the version of the sub process group stays on the
feature branch that doesn't exist anymore when it's merged.
Do you have any ideas on that? Or is there a "best practice" on how to work on
versioned process groups?
> NIFI flexible Version Control
> -----------------------------
>
> Key: NIFI-14159
> URL: https://issues.apache.org/jira/browse/NIFI-14159
> Project: Apache NiFi
> Issue Type: Wish
> Components: Flow Versioning
> Affects Versions: 2.1.0
> Reporter: David Pfingst
> Priority: Major
> Labels: gitlab, nifi, versioning
>
> As a NiFi User / Admin I want to run Nifi with a complete deployment via
> GitLab Pipeline so that it's not necessary to login into UI for bringing
> changes into production environment. I want to use NiFi mostly headless with
> a single admin user for service and other users only for monitoring purposes.
> At the moment I'm using the NiFi REST API in a Pipeline script to achieve the
> functions that aren't integrated into NiFi Version Control itself (deployment
> of the new version) but there are restrictions that would be too complicated
> to solve with the API. For an example the running state of the single
> processors should be possible to get via version control. When I change the
> state of a processor on my developement environment (local NiFi) this state
> should be set on the production server as well when I deploy the new version.
> My wishes for a flexible Version Control:
> * Select per process group what should be versioned (checkbox for services,
> running states, etc.)
> * Version Control of Parameter providers (maybe passwords fillable with
> CI/CD Variables from GitLab?)
> * Position of the Processor in canvas (could help with automatic deployment
> via GitLab)
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
