chore: Migrate to docker compose v2

[BobdenOs]

docker-compose (v1) has been replaced for a little while now with docker compose (v2), but for Docker Desktop there is an alias docker-compose which actually is (v2) which created a miss match between the GitHub Action and the local development setup as the container name changed from hana_1 to hana-1.

This PR aligns the two by switching to docker compose (v2) for the GitHub Actions as well. As the GitHub Action default runner seems to have removed the docker-compose (v1) command.

[gregorwolf]

Hi @BobdenOs ,

checking the container images defined in the YAML files I see only images used that are not public. Wouldn't it be better to work with a HANA Cloud instance instead? Or can you convince someone internal to re-publish the HXE image?

Best Regards
Gregor

[BobdenOs]

Hi @gregorwolf,

The HANA Express images are publicly available here (Last pushed 25 days ago). It might not be clear in the YAML files as for action startup times we use a pre-started image. Which saves ~4 minutes of start up time.

I specifically decided against using a HANA Cloud instance, because of the following reasons:

• It is easy to leak secrets (docs)
• Secrets are not available inside PRs from forks (*1)
• Having HANA Express as baseline allows anyone to contribute to the project
• Using a local HANA instance greatly improves test performance (*2)
• It would require a special HANA Cloud instance for this repository (*3)
• (redacted)

*1 It is possible to enable secrets in PRs from forks, but this makes leaking secrets trivial.

*2 As GitHub Actions are a black box to us. It is not possible to determine where the Action will be executed. So even when using a HANA Cloud instance that is running on Azure. There is no guarantee that the HANA Cloud instance and the Action runner will be in the same data center / continent. Which comes with a large impact on the networking performance as a side effect of how the HANA network protocol is defined. Where internal test suites have shown a variance in runtime of 3x the base line. While local HANA Cloud instances have around 0.1x variance in runtime. Even when running on the default GitHub Action runners which don't meet the minimal requirements of HANA Express. Which means that there is no need to set the test timeout to 60seconds which means that if something goes wrong the test run will fail quickly.

*3 While we have access to development and testing HANA Cloud instances it would be required to run an additional instance to just serve this repository. As it is possible for anyone to make PR and push commits it would be required that the HANA Cloud instance serving these GitHub Actions would scale accordingly. Which is currently difficult to do as scaling up an HANA Cloud instance takes quite some time and additional privileges (BTP). Which if done using existing HANA Cloud instances would create the cascading effect of preventing internal PRs to fail when the HANA Cloud instance is being attacked through this method. Effectively creating a Denial of Development attack on this repository and all internal repositories that share the HANA Cloud instance.

Sorry for the long explanation, but I hope it provides some insight to the decision.

Regards,

[gregorwolf]

Thank you @BobdenOs for the details. Seems the search for https://hub.docker.com/search?q=hanaexpress is not providing the best result list. saplabs/hanaexpress appears, but it's not the top result and even after a imaged named the same way. Do you have any contact to the saplabs team maintaining the image? Maybe they can push Dockerhub to get the search result fixed.

[BobdenOs]

@gregorwolf I haven't had any direct contact with the SAP labs colleagues. I am also not sure how big of a deal it is that the image is not Search engine optimized. Especially as the first hit on Docker Hub has 1B+ downloads. While the SAP labs image has 10K+ downloads. Even the 6 year old image with the same name from an arbitrary user has 100k+ downloads.

Additionally when using a proper search engine the image page is the first hit(s) (google, bing). Sure Bing has 4 hits in the top 5 results that point to instructions on how to install deleted version of HANA Express using Docker. Not sure how much can be done about that at this point.

It is still a goal of mine to expose the HANA Express and HANA Cloud local development scripts from the @cap-js/hana package and the GitHub Action. To make it significantly simpler for developers to setup their own CI/CD and local development setups with full fledges HANA features.