Added GitUrl variable in frontend config, modified the GetFrontEnd Config to accept the variable, added PR number extraction and modified services to send the the PR number

As the state of the cluster can differ from that seen in kuberpult, it could be helpful to have link to ArgoCD for the service on a stage to quickly verify that the cluster actually has the state represented in kuberpult.

When application is manually deployed to production, check that all its upstream environments are already updated, if not give warning.

story: SRX-5VUIF9

This change allows a new parameter for the deploy endpoint version to make the endpoint (nearly) idempotent. The parameter is optional. If it's omitted, kuberpult will use the existing behaviour and use the latest release+1.

This also slightly changes the http status code. Until now, the status code 204 ("No Content") is used to indicate success. However, we have now two different success outcomes. To reflect this, kuberpult will respond with 201 ("Created") when a new release was created and 200 ("Okay") when the release already exists.

Allow releases that are created later to be sorted corretly by the commit history (of the source repo).

Current Situation

• Main build fails.
• there is the possibility to retrigger it in jenkins or github actions. However, this will always build the latest version (main branch). Even if there are 2 Commits that are new, these will be lumped together into one kuberpult release. This works technically, but it's confusing.

Goal:

• If a main build fails, it can be retriggered with a specific offset (in git commits). Even if there was another successfull main build in between.
• Jenkins will publish a new version. This new version is then sorted into the right place in kuberpult. It's not necessary the latest release.

Open Questions:

• How do we clean up old releases? Do we need to change this?
• How old can old commits be to be accepted? They shouldn't be older than a few days.
• When creating an "in-between" release, how do we handle deployment? We need to make sure "upstream" is not deployed then, because it would be a downgrade.

• rename "All Locks" -> "Locks"
• make 2 secions: "environment locks" and "app locks"
• in the release dialog, show both the name AND the id of the lock.

We have the use case where kuberpult is used with many teams and each team would like to trigger a release train for their services only. This is especially important if you have quality gateway tests which block the release train:

e.g. a qualitygateway test of team A currently does block the release train for all services and teams.

I think it might make sense to allow specifying a prefix for the release train.

E.g. to say that only services with this prefix should be deployed.

https://revolution.dev/app/-JqFGExX46gs9mH7vxR5/-M37cZx7XYoOvQ5Mmcir/FILESYSTEM/FOLDER/ROOT/STORY/-Mp6i5lzSJREYmTNHy6p

When the config.json file in any of the environments is an invalid json file (missing file is ok) then do not start kuberpult cd-service, throw a valid error message and quit, do the same in /health check as well.

An easy way to have a filter for large teams, would be to add a query parameter, like ?q=foo this should then only display all services with "foo" in the name.

Not having to manually install the protoc-gen-* binaries enables simplifications of the start.sh scripts and makes the docker-compose start more robust. Additionally all tool dependencies required to generate protobuf code is now in buf.gen.yaml instead of split between that file and go.tools.mod.

The versions used in go.mod and buf.gen.yaml have to be kept in sync! (Previously, the versions used in go.mod and go.tools.mod would have to be kept in sync.)

This also removes manual installation of libgit2 and a yaml library. libgit2 is already a dependency in go.mod and the yaml library was not used. I included both removals in this commit (even though they are unrelated), because that allowed some simplification of the makefile code in the .install target.

This also updates protoc-gen-go from 1.26.0 to 1.28.0, protoc-gen-go-grpc from 1.1.0 to 1.2.0, protoc-gen-grpc-gateway from 2.4.0 to 2.10.0.

Story: SRX-Y9BRXK Story: https://revolution.dev/app/-JqFGExX46gs9mH7vxR5/-M37cZx7XYoOvQ5Mmcir/STORY/-Mwb00UWgoLeu2OucGwW/

Idea: Simplify the process of undeploy. Currently it's a bit long and tedious to wait for all release trains.

On the first button to create an undeploy version, we could ask the user:

Do you want to deploy the "undeploy" version immediately? Note that this includes a deployment to every environment. You should only do this if you are sure that the service is not needed anymore on any environment.

Then add all deployment actions to the cart.

go-billys WriteFile function has a funny behavior: It does not allow overwriting an existing file with empty content. We work around this by giving the file a single space. For argoCd this should not make a difference