We are using jBPM EAP 6.4 version. We are developing the JBPM workflows and rules using business central console tool.
We want to implement Continuous integration in our project. How can we implement the CI if we use Business central console for our changes ? Normally Jenkins (other build server) listens repository server for changes, as soon as developer pushes the changes to repository, immediately it will trigger the build and deploy.
But in our case we are developing everything using the console.How to achieve CI in this special case or any recommended approach to implement CI in jBPM ?
Can you please suggest..
Thanks
Just a pointer,
The work bench (business central control) is pointing to a git repository (by default), so essentially, when you are interacting to the work bench, you are doing actions very similar to a normal scenario, that is, where a developer commits to a git repository.
User documentation jBPM - VFS repository
Hope this gives a direction.
Repositories in Business Central use virtual file system based on Git and each time you save something in one of the editors a commit is made. You can create a Git hook on your repository which will trigger some action after each commit.
Related
We are in process of versioning microservice for parallel deployments.
During this process we are versioning the entire service by following git release branches i.e. cut release branches from main during the release and maintain release branches as supporting that specific release.
Now we have a problem we are trying to solve which is Spring Cloud configuration.
We have external config server deployed which gets the configuration from Git repo.
What is best way to version the configuration properties or yaml files?
We have brainstromed different ideas like
single git repo and multiple branches for different version for e.g. service-v1 gets config from v1 branch and service-v2 gets config from v2 branch
single git repo and single branch but use prefix key and suffix as version for e.g. key1.v1=v1, key1.v2=v2
Please let me know what is better/clean approach or any best practices for solving this versioning of of configuration.
Thanks
I want to design a Spring Boot REST API using GitLab's API to pull the specific repository branches from GitLab.
Requirement
We have been working on a big project and that project functionality is getting split into nearly 15 microservices and we have a GitLab repository for each microservice to organise the code remotely. And each repository has many branches like
master branch
dev branch
prod branch
And when we do have a prod release by that time we are raising merge request from dev branch to prod branch by logging into GitLab. And same practice we are doing for all other microservices which need prod deployments. So, here we think rather logging into gitlab and raising merge request from one branch to another branch every time.. we would like to write some Spring Boot service which consumes GitLab services like pulling specific repo details like its branches and other info and then raise merge request from one branch to another branch
So here we mainly looking for two operations one is pull the repository branch details and once pull the branches then raise a merge request from one branch to another branch.
Pull repository branches
Make branch merge request
And we are ready with React UI at client side and looking at REST services with above operations.
As I haven't worked before on such API implementations, I am interested in how achieve the same.
You will want to look into the use of Spring's RestTemplate from the spring-boot-starter-web project. You can use the RestTemplate to call the GitLab APIs to perform your operations on each of the repositories.
Now, there is a lot of information on this subject and a full write-up would be enormous so my suggestion would be to read through Spring's guide on building REST APIs. Baeldung also has a nice little introduction to the rest template that can be found at https://www.baeldung.com/rest-template
I have a clustered application architecture, where 3 of my primary services make use of a dependency artifact (lets call it commons) that contains the modal files and other utils used by other 3 services.
Presently, I have all the 3 spring boot applications deployed on k8s through Gitlab CI via artifactory for image management.
Now, each time I make changes to my commons service, I have to change the version of the commons in pom.xml(so that it doesn't conflict with the previous artifactory image) and also change the pom versions of my other 3 services that depend on this new version and push all the 4 (first push commons so that the new build image is available in artifactory, and then the other 3) services.
Is there a better way to manage this. I would have preferred if, my 3 services where able to fetch the latest common version and add it to my pom version
This is currently supported in Reliza Hub (disclaimer: I'm developing the project).
The workflow to get latest release is documented here (see workflow 2.Get Latest Release Of A Project Or Product).
Idea is the following:
you define project for your Shared Library and configure from GitLab CI to automatically stream build metadata to Reliza Hub on every build using Reliza Client.
Automatic versioning can also be maintained via Reliza Hub (meaning that Hub would increment versions for you on every build based on your chosen versioning schema) - you need to use getversion command of Reliza Client for that.
You can then use this automatic version increments to update version in your pom.xml at build time. So this process will be fully automated.
Once that is done, in your CI pipelines for each of the 3 dependent services, you include call to Reliza Hub using getlatestrelease command of Reliza Client for your shared library. This call will return you back all metadata for the latest release of shared library, including its version.
You can then plug this version into pom files of your dependent services.
Hope this helps.
I'm using nexus2artifactory tool to migrate form nexus to artifactory (as tool's name obviously says) and am facing a strange behavior and was wondering if I'm doing something wrong.
I'm trying to migrate some maven repositories created on nexus which handle snapshots and which should be set with UNIQUE as "Maven Snapshot Version Behavior" (default when creating a maven repo in Artifactory) but after the migration all my snapshots repos are set with NON-UNIQUE which is quite annoying especially when using maven3 where the support for uniqueVersion tag was dropped.
Am I alone with this problem ? What can I do to migrate these repos differently ?
Thank you in advance for your kind explanation
The reason for this behaviour is that the nexus2artifactory tool is using the Artifactory REST API for creating the repositories.
The default value for snapshotVersionBehavior when working with the REST API is non-unique (for legacy reasons).
This should be fixed in the nexus2artifactory tool (and possibly also change the REST API defaults). In the meantime, if you need a quick fix, the following could be added to Artifactory.py:
jsn['snapshotVersionBehavior'] = 'unique'
Dear All,
I'm new to GIT and i want to move from SVN to GIT, in my application I'm using web services, for each web service i have bundle for API, bundle for IMpl, and another for service.
I want to make branches for each web service to contain service and WS-Impl. and another branch that will contain all WS-API. the reason is to limit access to the code.
If you want to apply access rights, then i would suggest to put the API projects in separate Git repositories. Branches aren't there for this case. So you would have one repository for the API project and one repository for Impl and Service.