. . .

Introducing the new git flow

Starting with ApiOmat Yambas 3.0, we've fully reworked our git feature.

The old handling had shown some drawbacks in the common usage of the feature, which we wanted to resolve with the new flow. We want to explain the new handling and its advantages on this page.

With the new handling, there is no difference between git-based and ant-based modules anymore. Furthermore every ant based module can be a git module!
The main idea of the new git handling is, that native modules are handled internally the same. Modules with appended git data can always be used to push the current state from Yambas to the repository or pull and deploy it from the repository to Yambas. In the meantime, there is no interaction between Yambas and the git repository. That brings the great advantage, that the repository does not have to be available to Yambas all the time (e.g. on server start).

With that idea in mind, the flow becomes far more clear and simple.
Furthermore rare problems of the old behaviour are gone now; e.g. where a checkout (GET /git), git init and a push (GET /gitPush) could have lead into unexpectedly pushing data to the repository or into an unwanted re-deploying processes of the module.

The new flow boils down to the behaviour of these endpoints:

  • POST /yambas/rest/modules/{moduleName}/gitData

    • Appends the git repository information to the module. If the module already had git data attached, the old data is overwritten.

    • The data is stored per system, depending on the X-apiomat-system header that comes with the request.

    • the (old) endpoint POST /yambas/rest/modules/{moduleName}/gitinit is equivalent and works the same, but has been deprecated in favor to this endpoint

    • now also supports subfolders (see below)

  • GET /yambas/rest/modules/{moduleName}/gitData

    • Shows the current git data

    • the commitId field shows the id of the last pull from git (see next point)

  • GET/POST /yambas/rest/modules/{moduleName}/git - "Git Pull"

    • checks out the repository and branch which was defined in the gitData and deploys it to Yambas (if it contains the module code)

    • if the repository does not contain the module, it will generate the module code and deploy it (just like the makeNative endpoint)

    • the update process depends on the "update" parameter of this endpoint, which may either be "true", "false" or "overwrite", like the sdk.property value

    • the commitId in modules git data will be set to the checked out commit

    • nothing will be pushed and the checked out repository will be removed from file system after the deployment is finished

  • GET /yambas/rest/modules/{moduleName}/gitPush - "Git Push"

    • checks out the repository, creates the updated module files and pushes them to git

    • the module deployed on yambas will remain the same (use the GET ../git Endpoint to deploy a changed state)

Beside that, the REST-API changed:

  • the moduleStatus field of the Module JSON can now only have the values STATIC, DYNAMIC or NATIVE. The NATIVEGIT type has been removed.

  • the Module JSON now contains a new field "isGit", which indicates, whether a module has git data attached or not

  • (as said before) the /gitinit endpoint has been deprecated

Subfolders:

You can now put multiple modules into one git repository. The modules git data now have a special field "subfolder" to specify a folder in the git repository where to find the module (and push the changed files).

You can also use our structure for integration tests and Yambas will detect such a structure automatically. Even when you're only specifying the root-level of the structure.

Example: Your git-repository is structured as the following:

  • / (root directory of the checked out project)

  • /smtp/smtp (containing the module files of module SMTP)

  • /smtp/smtp-integrationtest (containing the integration-test files of SMTP)

  • /smtp/Jenkinsfile (Jenkinsfile for module SMTP)

  • /ldap/ldap (containing the module files of module LDAP)

  • /ldap/ldap-integrationtest (containing the integration-test files of LDAP)

  • /ldap/Jenkinsfile (Jenkinsfile for module LDAP)

  • ...

Now you can create a Module SMTP and its git data referring to this repository and specifying "smtp" as subfolder. Yambas will then check the subfolder, detect the structure for integration-tests and update the subdirectory automatically to smtp/smtp and work in this directory.

Additional Remarks:

We will now automatically generate a .gitignore file for modules directory for the first pushed commit. The directories "bin", "build","target" and "dist" will then be gitignored.

There is no automatic task that pushes changes to the git repository anymore. If you want the git repository to be up to date to the state defined at Yambas, you have to manually push the changes to the repository.

Nevertheless, if you want Yambas to be up to date to the code in your repository, you can use the Git automatic pull trigger integration, as you already could do before.