Project repository moves for modeling.viatra

As part of our ongoing plan[1] to modernize our services we are now moving project repositories from git.eclipse.org to Gitlab/Github.

Webmaster needs to know:

1. If the project would prefer to move their code repositories to Gitlab or Github
2. What timing would be best for the project. By default it will be the due date of this issue.
3. What should happen to the open bugs for the project.

We'll coordinate via this issue and once the move is complete committers will need to update any local copies of the repositories, as well as any build jobs to point at the new remote URL locations.

If we haven't heard from the project by the due date for this issue, Webmaster will request a review from the EMO team to make sure the project is still active. Project repositories for active, but unresponsive projects will be moved to the Foundations Gitlab instance by default, and their bugs will be archived.

[1]https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Gerrit/Gerrit-and-Bugzilla-deprecation-and-migration-plan

/cc @ahegedus /cc @irathyxf /cc @zujhelyi /cc @dvarro

changed due date to February 15, 2024

added IT-prioritymedium IT-severitylow Migration ~16281 ~55076 team:infra labels

assigned to @mward

subscribe

We will discuss this with the project and I will return shortly with the results (in about a week).

We'd like to handle this migration as follows:

• We don't have any strong timing constraints, we'd like to clean up our existing open Gerrit changes before the move (it is easier not to move incomplete changes), but if we have a month of time to do that, it would be fine for us, so between December 2023 and February 2024 we can accommodate any suggested time.
• We'd like to move to GitHub.
• We have one repository (https://git.eclipse.org/c/viatra/org.eclipse.viatra2.vpm.git/) that we don't consider worth the effort migrating, that had not been touched for years, and we consider it ready to be archived.
• We'd like our tickets to be moved to Github, if possible, on a per-component basis:
  • The component VPM Archive is related to the org.eclipse.viatra2.vpm repository to be archived, so they tickets should not moved.
  • The component 'Examples' relates to the org.eclipse.viatra.examples repository.
  • The component 'Obfuscator' relates to the org.eclipse.viatra.modelobfuscator repository.
  • All other components should be moved to the org.eclipse.viatra repository.

Do you need any other information from us?

Sorry for the delay in following up on this.

I think this is all we need to move forward. Is sometime next week ok for timing?

Next week is fine. To clarify, I'd like to ask what is expected from us during the migration.

[...] what is expected from us during the migration.

We will handle the migration. After the migration, you will only need to adapt your local and CI configurations and update the repo URLs.

Just as a heads-up: due to the very restricted GitHub API for importing issues, a lot of meta-data will be lost (e.g. issues can not be back-dated, issue authors and commenters can not be set correctly). Hence, most projects decided to start fresh with GitHub issues.

Thanks, that is reasonable.

About the tickets, I understand the limitations here (I have tried to migrate a Gitlab repository to Github and had the same issues). Still, I believe for us it would be easier for us to have the historical tickets available in Github even in this form than to try and recreate the ones we are working currently or handling the two systems in parallel.

@mward, @fgurr Could you estimate when we should expect the migration to proceed?

Last week would have been fine. This week is not optimal because I will not be available between Wednesday and Friday, but possible if necessary, next week would be fine.

Thanks for the information.

Sorry about that. I've scheduled this for March 4th at 1:30pm Eastern(so ~7:30pm CET) .

One question: which repository is the right destination for the converted bugs?

Date is fine.

About the tickets, if possible, please do it by original component, as written above:

• The component VPM Archive is related to the org.eclipse.viatra2.vpm repository to be archived, so they tickets should not moved.
• The component 'Examples' relates to the org.eclipse.viatra.examples repository.
• The component 'Obfuscator' relates to the org.eclipse.viatra.modelobfuscator repository.
• All other components should be moved to the org.eclipse.viatra repository.

If this is not possible, then move all to the org.eclipse.viatra repository.

---

One more thing: can I ask for the Github Discussions being enabled for the repositories? It would be our replacement for the forum (that is also planned to be removed AFAIK).

Pretty sure that discussions are on by default.

mentioned in issue #4146 (closed)

marked #4146 (closed) as a duplicate of this issue

marked this issue as related to #4146 (closed)

The repositories have been imported to Github. Committers that have added their Github IDs to their Eclipse.org accounts will receive invitations to join the Viatra Github team in an hour or so when the sync tooling runs.

Committers will also need to update their local repos and any build jobs to point at the new remotes.

I also took the opportunity to move the viatra-website repo into the new Viatra organisation, just to keep things a little cleaner.

The Gerrit repos have been marked read-only and a pointer to the new locations added. The PMI metadata has also been updated.

Which just leaves us with the issue transitions. I'm going to need to coordinate with the RelEng team to get the bot user setup to do the actual moves.

You may also want to consider enabling Otterdog for self service(https://www.eclipse.org/projects/handbook/#resources-github-self-service). If that sounds good to you, please file a helpdesk issue and we'll get it setup.

/cc @heurtemattes /cc @pastanki

Thanks, the repositories themselves look fine. However, I have noticed a few issues:

• We would like to use the Otterdog service.
• Discussions were not enabled. When looking at the Otterdog service, I have seen the default settings were these are disabled. We are fine with using Otterdog for setting this up, I have seen the relevant option there.
• When trying to update our main Jenkins build to use the new repository, I have received a rate limit exceeded.
• Question: is our Jenkins instance able to report back to Github commits using the Checks API without any credential (I did not see any on our Jenkins instance)? Or do we need a specific user for that?

• When trying to update our main Jenkins build to use the new repository, I have received a rate limit exceeded.
• Question: is our Jenkins instance able to report back to Github commits using the Checks API without any credential (I did not see any on our Jenkins instance)? Or do we need a specific user for that?

The RelEng team will create a GitHub bot user to handle that.

I've enabled discussions to keep things moving, and will try to remember that they are not on by default in future.

otterdog has been enabled for the eclipse-viatra organization. The following repo has been created:https://github.com/eclipse-viatra/.eclipsefdn You can find the current configuration at https://github.com/eclipse-viatra/.eclipsefdn/blob/main/otterdog/eclipse-viatra.jsonnet

A dashboard ui of the configuration can also be accessed at https://eclipse-viatra.github.io/.eclipsefdn/ which also provides a playground to test snippets before making a PR. When you want to suggest changes, fork the repo, make changes and create a PR. A workflow will automatically run and show you the changes that will be applied and validate that the configuration is correctly formatted and composed.

The documentation of all supported settings can be found here: https://otterdog.readthedocs.io/en/latest/reference/resource-format/

A list of all Eclipse projects that have it also enabled can be accessed here: https://eclipsefdn.github.io/otterdog-configs/ That is often quite helpful to get ideas about others do their configurations.

Otterdog is also deployed as github app and its commands can be invoked from within PR: https://github.com/eclipse-csi/.eclipsefdn/pull/6

A GitHub bot (ID: eclipse-viatra-bot) has been created. Credentials have been added to the viatra JIPP.

The recommended way to set up a job that builds pull requests is to use a Multibranch Pipeline job (a Jenkinsfile in your repo is required):

1. New item > Multibranch Pipeline
2. Branch Sources > Add source > GitHub
3. Select credentials "GitHub bot (username/token)"
4. Add the repository URL
5. Configure behaviors
6. Save

By default, all branches and PRs will be scanned and dedicated build jobs will be created automatically (if a Jenkinsfile is found).

If you have any problems let us know.

added team:releng label

assigned to @heurtemattes

The Viatra bugs have been imported to Github, so I think we're done here.

closed

I agree, I have tested the migrated infrastructure and it works.

However, I have a feedback about the issue migration: the fact that the bugzilla links point to the API server of Github (e.g. https://api.github.com/eclipse-viatra/issues/org.eclipse.viatra), it means, the entered links are basically broken. The best link would have been a direct issue link, but a working link to the repository would also be better than the ones we got.