gCTS thoughts
gCTS is now an option for transporting and storing the codebase using a git-based server. One of the key point to realize is the fact that gCTS is CTS plus “g(it)”. It is still the good old transport system, but backed up by Git which adds some benefits. Comparing to abapGit, gCTS it is not so feature rich but might be easier for teams not accustomed to Git specifics and when they are using traditional single-server dev environment. abapGit has much more “usual” Git inside, giving you much more control over the code you want to commit (patch, diff, tags etc.).
From my not-so long journey with gCTS what I observed is:
-
The way you want to start to use gCTS matters. For totally new projects it is easier, for existing ones you need to plan the migration – switching packages to a new transport layer is one thing (as far as I know there is no tool for doing this automagically for the package hierarchy, you need to go to each one package and adjust), the other headaches I had was not paying attention that some objects from packages switched to gCTS were still locked in transports with my old transport layer. The best is to have all required objects released and then do the switch.
-
Pay attention to the logs accessible in Activities tab and clicking on the transport (or request ID in the after-dev systems).
- What happens if you use the same vSID for another repository? Here is a scenario – I have ZSAMPLE_1 package configured with vSID RE1. Then added ZSAMPLE_2 to another, new repo with RE1 vSID. Packages were also added to ZRE1 transport layer. When you release the transport dedicated for ZSAMPLE_2, changes will be committed to the repo of ZSAMPLE_1 too. The first sign you will find in the log of the transport:
- As you see there are 2 VCS Checkin and imports. In the repo for ZSAMPLE_2 I have my objects (from A4HK900065) as expected:
- …but the repo for ZSAMPLE_1 package also gets the changes for ZSAMPLE_2:
- So pay attention about these vSIDs/transport layers. The CDS below can be used to check
- packages assignment to gCTS generated ones.
@AbapCatalog.sqlViewName: 'ZVSID'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'vSIDs and packages'
define view z_vsid
as select from tmscsys
association [1..*] to tdevc as _packages
on $projection.TransportLayer = _packages.pdevclass
{
concat('Z', sysnam) as TransportLayer,
sysnam as vSID,
_packages
}
where
(
systyp = 'N'
or systyp = 'V'
)
and systxt like 'gCTS%';
- As a remote repo server not only major vendor ones can be used – I was playing around with Gogs
- (as a container), it was working without problems and it is nice option if you don’t want to
- mess with your GitHub/other online account. The setup I have for Docker-compose:
gogs:
container_name: gogs
hostname: gogs
ports:
- "10022:22"
- "10880:3000"
image: gogs/gogs
volumes:
- "gogs_data:/data"
- The quickest Gogs setup is to use SQLite as db, no SSH, user + password as authentication.
- Then in gCTS just use HTTP, in my case when I’m running ABAP Trial also from Docker, so using internal (Docker) ports:
- If the hosting provider of your choice offers workflow/processing features, then you can use it to fill some gaps of missing Git features and use it to bring more interesting post-processing steps. Here are sample actions like echoing only changed ABAP files with git diff and creating a pull request to the main branch on push to the dev branch.
- GitHub action file:
on:
push:
branches:
- dev
jobs:
create_pull_request:
name: Create pull request
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Create PR
uses: repo-sync/pull-request@v2
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
destination_branch: "main"
pr_title: "${{ github.event.commits[0].message }}"
pr_body: ":crown: *An automated PR*"
pr_label: "auto-pr"
# Log changed ABAP files
# Set the changed files as output for another step
changed_files:
name: Changed ABAP files
runs-on: ubuntu-latest
outputs:
abap: ${{ steps.changes.outputs.abap }}
steps:
- name: Checkout repository
uses: actions/checkout@v2
with:
fetch-depth: 2
- name: Changed files
id: changes
run: |
git diff --name-only --diff-filter=ACMRT HEAD~1 | grep .abap | sed -E 's/objects(.*)/\1/'
echo "::set-output name=abap::$(git diff --name-only --diff-filter=ACMRT HEAD~1 | grep .abap | sed
-E 's/objects(.*)/\1/' | xargs)"
# Sample - use output from previous step
print_changes:
runs-on: ubuntu-latest
name: Changed ABAP files from other step
needs: changed_files
steps:
- name: Print changed files
run: |
echo " Changed ABAP files:"
echo ${{needs.changed_files.outputs.abap}}
PS. This article is also published on SDN: https://blogs.sap.com/2021/11/13/gcts-with-gogs-github-actions-and-some-thoughts/