How does one create Pull/Merge Requests that have a complete git history?

[aaron-lunsford-even]

We ran into an issue, similar to this one, today while working with one of our git repos: #2692

The workflow we're trying to implement is for updating values in a helm chart we control:

1. Warehouse connected to public, 3rd-party Github repository
2. git-clone default branch of a repo we own
   a. Specify a branch name and set create: true
3. Update a helm values file with yaml-update
4. git-push
5. git-open-pr
6. git-wait-for-pr
7. On merge, a pipeline builds the helm chart and pushes to ECR
8. Warehouse connected to ECR does its thing and promotes the chart through environments

We use Gitlab so Merge Request = Pull Request.

Steps 1 through 4 didn't work because the new branch is orphaned and empty, so we tried using copy to copy files over from the default branch to the new branch, but the new branch is always N number of commits behind the default branch since the new branch does not have the commit history of the default branch. Example:

        - config:
            checkout:
              - branch: main
                path: ./testing-in
              - branch: someNewBranch
                create: true
                path: ./testing-out
            repoURL: https://example.gitlab.com/myrepo.git
          continueOnError: false
          uses: git-clone
        - config:
            inPath: ./testing-in
            outPath: ./testing-out
          uses: copy

Even after reading through the linked discussion, I'm struggling to understand what the purpose of the orphaned branch strategy is and why someone would use it, and why there would be options for creating branches, pushing to them, and opening merge requests if history is not preserved? It just results in merge requests that are un-mergeable because of the history discrepancy.

Maybe our setup is just not compatible with Kargo since we do not use long-running branches in our gitops strategy?

Any insight would be appreciated. Thanks!

[krancour]

The discussion you linked to is pre-GA. The Kargo of today is virtually unrecognizable in comparison to what it was then, so you can dismiss that thread entirely.

If I understand your desired workflow correctly, what you want is to check out a branch tracking an existing remote branch (let's say main), make some modifications, commit, then push that to a new remote branch with common history with main so you can create a PR.

In the shell, something like this:

git checkout main
git pull origin main
# make changes
git add .
git commit -m "my changes"
git push origin main:new-branch # Will have common history with main
# open pr with new-branch as the source branch and main as the target

As Kargo steps:

- uses: git-clone
  config:
    repoURL: ${{ vars.gitRepo }}
    checkout:
    - branch: main
      path: ./src
- uses: yaml-update
  # yada, yada, yada
- uses: git-commit
  config:
    path: ./src
    message: updated values.yaml file with ${{ yada, yada, yada }}
- uses: git-push
  as: push
  config:
    path: ./src
    generateTargetBranch: true # New remote branch; common history with main
- uses: git-open-pr
  config:
    repoURL: ${{ vars.gitRepo }}
    sourceBranch: ${{ outputs.push.branch }}
    targetBranch: main

[aaron-lunsford-even]

Wow, I'm not sure how we missed this permutation when we were debugging. I suppose we still had the branch config set to the new target branch in our clone step while also having it in the push step.

Either way, thanks for clarifying. Can confirm your suggestion works as intended! 👍