Skip to Content
Technical Articles

Experiments with ABAP Platform 1909 Developer Edition gCTS and AbapGit on locally hostet Gitea-Server

With ABAP Platform 1909 Developer Edition I started to try out gCTS compared to AbapGit. But my plan is to build an automation toolchain on my local computer to simulate how to use in a business context.

So after getting Abap platform 1909 running very easily (after upgrading my RAM 😛 ) I wantet my own local “mini” Git-Server. I decided very quickly to use Gitea. It’s really lightweight and easy to install with Docker. Also the user interface is almost similar to GitHub.

Install Gitea with Docker-Compose-File

Dockerhub

docker-compose.yml

version: '2'
services:
  web:
    image: gitea/gitea:1.12.4
    volumes:
      - ./data:/data
    ports:
      - "3000:3000"
      - "22:22"
    depends_on:
      - db
    restart: always
  db:
    image: mariadb:10
    restart: always
    environment:
      - MYSQL_ROOT_PASSWORD=changeme
      - MYSQL_DATABASE=gitea
      - MYSQL_USER=gitea
      - MYSQL_PASSWORD=changeme
    volumes:
      - ./db/:/var/lib/mysql

After running docker-compose up -d I had my Gitea-Instance running on http://localhost:3000/ .

 

Gitea

For my first Test with AbapGit I created a repository Test_A4H_AbapGit.

Now I can clone the repo link http://localhost:3000/sascha/Test_A4H_AbapGit.git and use it with AbapGit. But because you communicate between two running containers you have to change to http://172.17.0.1:3000/sascha/Test_A4H_AbapGit.git

After that I started ZABAPGIT and cloned the Gitea repo.

So to try everything works I created a simple Report and pushed it to the remote master branch. After entering my credentials the push was finally complete.

But I also want to try scenarios with gCTS so I did the same procedure with gCTS which is almost completely preconfigured on ABAP Platform 1909 Dev Edition. I only had to start Fiori Launchpad.

After starting gCTS you have to enable gCTS with some pre-configured steps. Then I created my first gCTS-project. (Of course, I first created a corresponding repository on Gitea)

Then I I cloned the repository first. Before pushing a manual selected object to test I added my credentials. Before I did that, I had some nondescript pushing errors. You do this in the configuration tab with the parameters CLIENT_VCS_AUTH_USER and CLIENT_VCS_AUTH_PWD.

After that you can select an object under the objects tab to try.

Finally Push 🙂

I already run a Jenkins CX instance under Docker to use Project Piper. I’ll take a look at that next and try to connect it to Gitea. Another small step towards my own local and small automation toolchain… 😉

3 Comments
You must be Logged on to comment or reply to a post.
  • It's got to be a Monday morning thing for me these days.   So I'm reading the blog and it seems like you are creating a local version of GitHub.  Then you are using it to move your projects between systems.  In this way you can have multiple developers working on the save thing.   Making the collaboration seamless.   Is that the purpose of it?

    The "local" version could make your company more happy because they will keep the development in-house.

    So now as my brain is finally waking up after a bunch of tea this morning - why would this be an advantage over using traditional CTS?  We can use enhancement points to have multiple developers work on the same thing.   Is there something I'm missing?  (probably)

    TIA,

    Michelle

    • Hi Michelle, I think "git-enabled" CTS is about enriching ABAP with the standard of git. Excerpt from the Statement of Direction:

      The challenge for SAP is now two-fold: keep the advantages of a central development environment, and make sure that ABAP development processes can be handled similar to the ones which are common on other platforms. This includes, in many development environments, the option to set up new development or testing systems with any selectable state of the coding.

      [... The] transport process has its pros and cons. It helps a lot in highly regulated environments, but in many cases, it is not flexible enough and does not work with state-of-the-art development processes and tools that are used in CI or DevOps. Especially if you work in a heterogeneous development environment which includes non-ABAP applications,

       

      • Thank you!  Now it's making sense to me.  Thank you for the link to the document.

        To really simplify things for myself - "It plays well with others".  In other words, It is not just ABAP or even UI5...  Many different languages can be used and for different application that the company may own.   It's the PI/XI version for transports.