New test. tl; dr There is a way to update a repository migrated (drop it and import it
back, see 2nd run.)

I'm reseting the gitlab state again and doing a migration from scratch.

My tryout in T4334 made me reset an important file which now messes up everything.
I'm reseting the gitlab state again and doing a migration from scratch.

I'm gonna check again tomorrow.

Actions:

• connect through the gitlab ui
• Select the repository to drop
• Settings > General > Section "Advanced" > Expand > Bottom of the page click on "Delete"
• input the name of the repository to destroy and validate on "Yes, delete project"
• Cleanup eventually remains from the previous run on the host running the migration:

rm -rvf /var/tmp/migrate-gitlab/forgerie/{gitlab,phabricator}/swh-ansible

• Trigger back the migration:

A new one...

Got error running git command push with args ("gitlab" "--delete"
                                              "generated-differential-D1804-source") in dir /tmp/forgerie/gitlab/swh-jenkins-jobs

Thanks.

Looks like something is wrong in the operator state management.
For what I found on internet, it could be related to the cert-manager version but it should be already fixed. For example: https://gitlab.com/gitlab-org/cloud-native/gitlab-operator/-/issues/315
(The current cert-manager version in the cluster is 1.8.0)

After unstucking the migration again, i've come up with the avatar upload routine compliant with the last http client optimization change.
I had finished the migration and wanted to trigger it back from scratch to have a non-failure and timed scenario ok.

/me grunts
another one bites the dust:

Unstuck after some mob debugging ;)
There is a fallback which tries and use the git am command and fails as some git config is missing.
We unstuck it by adding some .gitconfig in the dockerfile declaration.

The migration did a lot more work this time. It finally crashed on the git am command though [1] [2] [3].

\o/ well done

• Private repository after migration are private.

And it seems it finished without any issues this time [1] [2]

Changing the command args from [1] to [2], the run cli no longer complains!

Booting: Unable to use a TTY - input is not a terminal or the right kind of file
Booting: --------------------------------------------------------------------------------
Booting:  Ruby:         ruby 2.7.5p203 (2021-11-24 revision f69aeb8314) [x86_64-linux]
Booting:  GitLab:       15.0.0 (8a186dedfc1) FOSS
Booting:  GitLab Shell: 14.3.0
Booting:  PostgreSQL:   12.7
Booting: ------------------------------------------------------------[ booted in 16.11s ]

• Report migration status

Status update:

• gitlab state cleaned up again (making sure host ssh key did not change, permissions ok, ...)
• triggered migration
• status report...

So i dug as to why my laptop was ok but not my desktop.

Better cli to execute...

forgerie@bespin:~$ logpath="/tmp/forgerie/run-$(date +%Y%m%d-%H%M).log"; echo "## Running migration logs in $logpath ##"; time /opt/forgerie/bin/run | tee $logpath
## Running migration logs in /tmp/forgerie/run-20220613-1410.log ##
...

Ah the migration scripts are still relying on the rails console to actually create merge requests... so we need that setup to work.
So i dug as to why my laptop was ok but not my desktop.

And now it fails on snippet creation which needs access to the rails console (in the current state of the migration script).
I've got no proper setup which allows this to work now [1].
The only way i see is to comment that part for now...

Migration failed again with a problem when creating a snippet [1]

The source of that issue was the ssh connection failing to be established [1]
Fixing with ssh-keygen [2]