Technical Articles
Be cautious when using Uninstall at abapGit
(First want to thank Paul Hardy help me start using those tools and thanks the authors of AbapGit to provide this great tool.)
Recently I try to install the excel tool ABAP2XLSX by using ABAPGIT ( copy&created program: ZABAPGIT_STANDALONE ) at the development system, I create one offline Git project then import by downloaded ZIP file for testing purpose first.
ABAP2XLSX is indeed a great tool to deal with Excel and those convenience features are very attractive. So I want to uninstall it to get a fresh start and move all related objects from the current un-transportable TR to one new request which can move to the quality system.
I went to the project details screen and thought it’ll uninstall this excel tool but the program begins to remove objects at the package where the tool installed, and I terminated the execution. But still, some objects been removed from the package at the development system.
-
It will now delete all objects in the package specified when installing the repository!
I couldn’t use &tmp package for movement and the transportable package couldn’t contain objects related to this new tool only. It’s my fault that I should double-check before click the uninstall button at ABAPGIT which already mentioned. But not striking enough, that’s why I mark here again as BOLD&RED!
-
It will now delete all objects in the package specified when installing the repository!
Fortunately, it’s a development system and I terminate the program execution to prevent it delete the whole package. I made the mistake and pay the price~ using several hours to re-create those deleted objects back. Don’t know if any better restore method from BASIS perspective, like copy objects from Q to D or restore specific objects from a backup. But it definitely costs a lot of effort.
So be cautious at abapGit that: Install is Install, but uninstall is not uninstall you installed! it’s the pure deletion of all the objects under the package where you installed!
One lesson I learned: Don’t take things for granted! uninstall at abapGit is not like uninstall one APP on a mobile phone or uninstall a Game on a PC.
—–Added at 2020/12/07—–
The package I used is a giant package for store all kinds of various ABAP objects include customized programs, screens, tables, etc. One example of deleted objects is the view maintenance overview screen like below:
It leads to missing at SE11 table maintenance screen. (It’s blank at this screen for screen fields like auth. group and function group.)
After recreated and get back the table maintenance, no logs show that my ID is the last changer. The function group and Table’ author/ last changed by still the same as before, and all the includes as well. Only the last changed date is my restore timestamp for this screen and version management shows no trace.
Don’t know it’s good or bad. But anyway, it’s been restored and tested which works as before, and no impacts for other systems…
Hi, thanks for sharing, bug reports are welcome on github.
Any suggestions to make it more clear that everything in the package is deleted? The text says “This will delete all objects in package”…
If you want to keep track of projects, the package level is used, don’t install multiple things in the same package or it will not be possible for you, or any logic, to determine which things belong where.
Also note its not possible to use $TMP for installation, to help the user to avoid above.
Lars Hvam
Good day. Thanks for the comments.
I install it at one ZXXX packages instead of $TMP package, sorry for the misleading as my 2nd screenshot is from abapGit linkage. I didn’t catch the screenshot when I click that uninstall button.
After I click the uninstall, the ZABAPGIT_STANDALONE program starts to delete objects from ZXXX packages, started with view maintenance along with its Transaction code (all belong to ZXXX package). Then I stop the execution and find all deleted objects been recorded to the transport request. (I refer to this to restore all deleted objects later.)
I don’t mean it’s a bug of abapGit. It‘s my bad for being careless and take ‘Uninstall’ for granted.
Yes, you’re right. I should create a new package for the new install of ABAP2XLXS instead of using the existing package which contains other objects. Thanks for the reminder, I won’t make the same mistake again : P
Btw, abapGit is really convenient for install tools contains lots of staff. well done.
regards.
Jigang.
Uninstall works like delete repository in Git, it deletes everything.
Uninstall is a double edged sward. Once, I had to delete all the objects from a package, I just created an offline repo using that package and uninstalled. Viola, all the objects are deleted.
May be the expectation is that to implement warning like git hub
Git Hub Warning Message
I'm surprised that abapGit deletes all the objects of the package, instead of just deleting the objects corresponding to the Git repository. Okay, the message says "deletes all objects of the package", but it's surprising, I would have thought of an unclear text. You won't be the only one to do the mistake.
Thanks for warning! (and I hope this abapGit feature will be improved)
For git in general one top level folder = one repository, which in abapGit means one top level package = one repo. There already were some issues reported with the wildest scenarios I would have never thought about (causing even more confusing things to be implemented like ignore subpackages and change_tadir). Give someone a tool and they will break it 🙂
abapGit cannot know which objects "belong to the repo" since objects may have been deleted or moved on the remote. Therefore the assumption is (and imo must be) all objects in the package belong to the repo (with the exceptions listed above).
I understand of course, but I think it would be better to say it clearly and propose two buttons, one to delete only the same objects, and one to delete the whole package and sub-packages. Many people just download a repository and don't change the objects.
So one button "Delete all objects that happen to exist on the remote if it even exists and is accessible and set to the branch you might want and still has the objects it had when you installed the repo" and one "Delete all objects in package and subpackages"? 🙂 "only the same objects" are not tracked in any way.
I think the different use cases clash a bit here. As you say many use abapGit as a "deployment tool" to get open source code installed on their system for use while the other use case is to facilitate development on the objects in the repos installed. Both are hard to combine into one client (and arguably git normally is more for the latter then the former).
In the same sense I initially thought one could at a warning on install if the package already contains objects. But then the warning would show up in the very common development use case of checking in an existing package into a new repo. If you pull into a package with lots of existing unrelated objects it should raise some concerns that they all show up as locally new and remotely not existing.
I thought we had a hash key table for "the same objects". Anyway, it's just my opinion that applications should be more tolerant with "non-expert" users. Anyway, considering that you have thought a lot about all implications, I guess a popup with a text highlighted like Ravi Andela proposed would be more relevant.
Maybe there is some way, I just don't know it. I think there's also some improvement on the user docs to be made. Couldn't find any remarks on packages in the install online / offline repo parts.
And git of course has a notorious learning curve which doesn't exactly help https://xkcd.com/1597/
Thanks for sharing!
My personal approach when trying new thing is to use a designated package, as others also suggested. If it doesn't work out, the whole package can be easily deleted. If it does - you can just as easily change the transport route for the package, dump the whole package in a transport, etc. Simple things work best. 🙂
Also if you just wanted to move this from a local package to a transportable one, this could've been done with transport / object directory tools as well. But otherwise it's an interesting experience, I guess.
I encountered this issue a while back. I should have written a blog about it!
At the time, I just made a mental note to always put git sourced code into their own package. It's a pain on some systems as they use just a handful of packages, and block the creation of new ones.
Yikes!
Regarding
You can create a transport of copies in your quality or productive system, and then simply transport them back to development system (if the package isn’t a local package like you wrote - $FOOBAR).
Yes, importing the ToC into DEV will restore those objects.
But careful: if you changed any objects in DEV already, without transporting them to QAS, then they will be overwritten.
You do not have to enter the missing objects individually, you can also include all objects from one package at once, with SE03, IIRC.
In a git context the developer will do a commit or open a pull request and automatically be
informed about the code. Typically this consists of compiling the code, static analysis, and running
unit tests.
Note that the developer is only interested in feedback about the current changes, so information
should be restricted to the current changes, not other changes ongoing in the same system(if any).
In git the developer will have a branch containing the changes, this branch is deployed to a isolated
system, which runs the toolchain. This can be a ABAP application server running as a container, for
each unit of work a system is spawned, code deployed, syntax check, code inspector, and unit testsn
are run.
However it might be difficult to spawn a ABAP system for each commit, so developers might be
forced to use the same ABAP system for continuous games integration, but note that this might give wrong
information to the developer. Also note that development happens in parallel, so continuous
integration should also run in parallel to ensure fast feedback.
abapGit is a community project and thus does not own any licences for running ABAP servers
connected to processes on the internet, so it is not possible to run continuous integration using
ABAP application servers for abapGit. Instead abapGit uses abaplint to perform limited static
analysis and provide feedback for eg. naming and downport problems. Branching in git is a central mechanism to separate development tasks. abapGit provides the basic
git features for handling branches, the feature is delivered to the users, and the users decide how to
use the features. As abapGit runs on the ABAP Application Server and developers use the
Application bookies server for development, all development is subject to the how the kernel works. The ABAP Kernel only allows one version of an object to be active at a time, ie. developers cannot have
multiple versions of the same program running at the same time, this also means typically git
branching is not possible within the same ABAP system.
If more active branches are required for development or testing, more application servers are
required in the landscape.
Hello Team,
i am getting below error when trying to connect ECC system to Bitbucket using abapgit
Please suggest
When trying to connect an ECC system to Bitbucket using ABAPGit, many users have reported encountering the error message: "Error connecting to server: Could not establish trust relationship for the SSL/TLS secure channel."
This error message can be frustrating and confusing, especially for users who are new to using ABAPGit or connecting their systems to external repositories like Bitbucket. However, there are several steps that users can take to troubleshoot and resolve this issue.
First and foremost, it is important to ensure that all necessary prerequisites are met. This includes installing the latest version of ABAPGit, as well as any required SSL certificates or other security measures. Users should also double-check their connection slots settings and ensure that they are using the correct URLs and credentials for their Bitbucket repository.
If all prerequisites are met and the correct settings are in place, users may still encounter the SSL/TLS trust relationship error. In these cases, it is often helpful to check the Bitbucket server logs for any relevant error messages or issues with the SSL certificate. Users may also need to make changes to their SSL/TLS settings in order to establish a secure connection.
One potential solution is to add the Bitbucket SSL certificate to the ECC system's trusted root authorities. This can typically be done by downloading the certificate file from the Bitbucket server and importing it into the ECC system's SSL configuration. Users should be sure to follow any specific instructions or guidelines provided by their system administrator or IT department.
Another approach is to disable SSL verification entirely, although this is generally not recommended as it can pose security risks. Users who choose this option should proceed with caution and be aware of the potential consequences.
Ultimately, troubleshooting the SSL/TLS trust relationship error requires a combination of technical knowledge, attention to detail, and persistence. By taking the time to carefully review settings, logs, and security measures, users can successfully connect their ECC system to Bitbucket using ABAPGit and take advantage of all the benefits that this powerful tool has to offer.