foreword
Recently, when using GitLab CI/CD, I found a "not smooth" usage scenario. The specifics are as follows:
As a developer, sometimes you need to be responsible for the deployment of several front-end projects at the same time.
After fixing the bugs in project a, you need to deploy to the test environment, and
after fixing the bugs in project b, you need to deploy to the test environment.
. . . .
Due to various reasons, the deployment of this scenario is not automatic, and the person in charge needs to manually create the deployment pipeline. For example, in order to provide testers with a reliable and stable test environment, a manual deployment environment will be used.
This leads to a problem. I need to enter project A first, click on the pipeline, select the corresponding branch, and create a pipeline.
Then enter project B and repeat the above operation.
The process is relatively cumbersome. The reason for this is that GitLab does not provide a pipeline management of personal Ower projects.
Similar to the domestic devops tool built in the picture below:
Since there is no pipeline management from a personal perspective, this requires us to enter the project to create a pipeline for a certain project. (Perhaps in the near future, there will be such a function).
The solution to this problem is very simple. Use GitLab OpenAPI to manage the pipeline, including querying the pipeline according to the project, creating or re-running the pipeline. But no matter if you want to write some pages, you still need to do some code for the backend to send requests to query GitLab data.
The specific idea is very simple, but I don’t have much spare time, so I put it on hold until one day I suddenly wondered whether I can use Node-RED, a low-code tool, to realize this global pipeline management function.
Node-RED is an IBM open source IoT project. It is a stream based build