Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking Discussion: Required steps for GitLab to LocalVC migration #8754

Closed
4 tasks done
b-fein opened this issue Jun 6, 2024 · 14 comments
Closed
4 tasks done

Tracking Discussion: Required steps for GitLab to LocalVC migration #8754

b-fein opened this issue Jun 6, 2024 · 14 comments

Comments

@b-fein
Copy link
Contributor

b-fein commented Jun 6, 2024

Is your feature request related to a problem?

Like the migration from BitBucket to LocalVC, a similar automatic migration should be possible for the migration from GitLab to LocalVC.

This issue serves as a collection/tracker to discuss required steps for this to be possible.

Relevant items that come to mind right now:

  • Clone all existing GitLab repos onto the Artemis server
  • Update all Jenkins build plans to replace the Git URLs pointing to GitLab to instead point to Artemis
  • Update the Git base URL in the programming_exercise_details table in the Artemis database
  • User documentation on how to perform the migration
@krusche
Copy link
Member

krusche commented Jun 7, 2024

The migration from Bitbucket to LocalVC can be found in chore/bitbucket-localvc-migration-release. It might be helpful.

@BaumiCoder BaumiCoder self-assigned this Jun 17, 2024
@BaumiCoder
Copy link
Contributor

BaumiCoder commented Jun 19, 2024

Why does the BitBucket to LocalVC Migration uses two extra keys for @Value? Both does not seem to be necessary for me:

  1. migration.local-vcs-repo-path could be replaced with artemis.version-control.local-vcs-repo-path, which already exists at the time of the BitBucket migration (e.g. used here).
  2. migration.base-url should be always equal to server.url. Or how can this be different?

@reschandreas can you maybe answer that questions, as the author of the BitBucket to LocalVC migration?

@reschandreas
Copy link
Contributor

Hi! I intentionally used different values to ensure that migration requires a deliberate action, preventing it from happening accidentally during updates. This way, the Artemis admin must consciously decide and update their configuration to migrate.

@b-fein
Copy link
Contributor Author

b-fein commented Jun 20, 2024

@BaumiCoder I guess with our plan to trigger the migration by a class with a special profile this then serves the same purpose and the different configuration values are not required.

@BaumiCoder
Copy link
Contributor

Thanks @reschandreas, with this background information I agree with @b-fein. I moved to the existing values for the migration here (see 55836b7).

@BaumiCoder
Copy link
Contributor

The log message here claims that the URL will not be changed in the database, because the migration failed. In contrast to this the lines 344 and 345 are also executed in this case, so the URL is saved, isn't? @reschandreas Is that intended or a bug?

@reschandreas
Copy link
Contributor

reschandreas commented Jun 27, 2024

looks like a bug to me. We changed the behaviour of the method several times (we weren't sure if we should keep the url or not), so this could have slipped through. I'm not aware of any issues during the migration though.

@krusche
Copy link
Member

krusche commented Jun 27, 2024

I think we had some entries in the database with the old URL. I always said this should not happen ;-) so it's probably a bug in the migration

@BaumiCoder
Copy link
Contributor

Okay, I fixed that bug (13e0764). However, this bug would have led to an null URL in the database (if that is possible). An old URL is still possible if some error blocks the migration of a repository (e.g. the source repository is not available anymore).

@BaumiCoder
Copy link
Contributor

Another GitLab specific thing is in the Artemis Database. If tokens are used for the authentication of the users against GitLab, Artemis stores these tokens in the column vcs_access_token of jhi_user. LocalVC also will have a token authentication (#8664). @SimonEntholzer Will your implementation be able to work with these tokens from GitLab, or should we delete the existing tokens (so that new ones are created if necessary)? I see two differences between the GitLab and the localVC tokens:

  1. Prefix: vcpat- at localVC / glpat- at GitLab
  2. Number of the characters after the prefix (digits and letters): actual 40 at localVC / 21 at GitLab (maybe depending on some GitLab configuration)

@BaumiCoder
Copy link
Contributor

To make sure that the old tokens do not cause any trouble or became unnecessary data, the migration now removes the token data (da6b3b3).

FYI: @SimonEntholzer

@dfuchss
Copy link
Contributor

dfuchss commented Jul 15, 2024

I've also updated our Test Container (LocalVC + Jenkins): https://github.com/kit-sdq/Artemis-SAML2-Test-Docker/releases/tag/v7.4.2-lvc

So this environment is ready to be used for testing as well :)

@BaumiCoder
Copy link
Contributor

Actual status:

  1. There is a migration available with Pull Request Programming exercises: Jenkins-GitLab to Jenkins-LocalVC migration #8972
  2. The documentation now contains a Jenkins-LocalVC section and Jenkins-GitLab section contains a warning that it will get removed.
  3. The issue Remove GitLab-related code before Artemis release 8.0.0 #9318 is about removing the GitLab related parts of Artemis.

Do we still need this issue here or should we close it?

@b-fein
Copy link
Contributor Author

b-fein commented Sep 20, 2024

You are right, I think this can be closed as resolved.

Thanks for the reminder.

@b-fein b-fein closed this as completed Sep 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants