Gitlab migration plan

Project Discussion
1

We are two steps away from starting the migration to Gitlab!
First one is getting the permissions set up : Currently handled by infra team
And the second one is the actual migration plan.

We currently have the following project tree on Gitlab to organize our repositories:

  • Community Tools Documentation - for Fedora Project tools & applications, ie.:
    • fedora-accounts
    • Koji/Bodhi
    • l10n
    • …
  • Docs Website - tooling and themes for generating docs.fedoraproject.org, ie.:
    • docs-fp-o
    • fedora-docs-ui
  • Fedora Linux Documentation - User Documentations, ie.:
    • fedora user documentation
    • fedora server documentation
    • quick docs
    • …

Other categories can be added as I’m not sure all our existing repositories can fit in these three.

We should start this migration with one repository first, just to make sure we didn’t miss anything.
And since we are close to F36 release, we should probably not begin with the user documentation, nor the main repository.

Migration steps:

  1. Create the gitlab repo and push latest content from its pagure counterpart
  2. Modify staging site.yml with the new repo
  3. Check if staging is building correctly
  4. Modify prod site.yml
  5. Check translation pipeline is working
  6. Move to the next repository

I also suggest we take this opportunity to stop using the master branch and move to main.

9 Likes
2

Following up on this from the meeting as I said I would…

+1 to using this opportunity to switch to main as the default branch.

I nominate the Overview - fedora-docs/documentation-contributors-guide - Pagure.io repo as our starting point. We should avoid docs-fp-o, release notes, and quick docs this close to release time just in case.

Everyone seemed in general agreement at last week’s meeting, so I guess I’ll just say: what do you need from the rest of the team, @darknao?

2 Likes
3

Alright then, I can start moving this repository over GitLab this week, and I’ll report back on the next meeting or/and here about the progress.
My guess is that repo is going to fit under the Community Tools Documentation, but the more I think about it, Community and Tools Documentation may be a better name for that category? Or do we need another one for all SIG / Community related documentations?

1 Like
4

Ooh bikesheds! I think “Community and Tools Documentation” is a good fit. Or an additional category for Docs meta repos, but I’m not sure what else would be there.

1 Like
5

Migration is complete, and deployed on staging.
New repository is here: fedora / Fedora Docs / Community and Tools Documentation / Documentation Contributors Guide · GitLab
I’ll leave it here for a couple of days, then do the same thing for prod.

3 Likes
6

Apologies as I seem to be out of the loop on this one. What is the reason for migrating to Gitlab? Will the entire Fedora Project migrate there as well?

1 Like
7

No worries :slight_smile: You’ll find the related discussion topic over here: Move Docs to GitLab - Fedora Discussion

2 Likes
8

I’ve opened issues for all of the repos and made a board using the gitlab label. A few of the repos are also tagged for meeting because we might want to do something different with them.

1 Like
9

Just a question: It looks like a hierarchical tree structure, do we have a kind of root repo for general issues, central dashboard, etc? (sorry, still can’t check myself, still have to solve my account issue)

1 Like
10

The fedora docs subgroup itself can be used to create boards and/or epics that can be used to group issues from any sub repositories.
I’m not sure you can create issues directly in a sub group.

11

How this will be reflected in teams docs? e.g.: SIGs and WG docs, e.g.²: i3 docs

12

For now, we are only focusing on repositories under the fedora-doc namespace.
Any content related updates (link to git project or anything else) are not included.

In your case, i3 docs are not impacted by this move since you have your own namespace (but you’re still welcome on Gitlab if you want to).

You can see all repositories that we plan to move under @bcotton board linked previously or over here.

2 Likes
13

Awesome. My next questions is if we moved our docs to GitLab (i3 SIG), what we need to do to have it published? @bcotton did his magic with the marketing docs, but I don’t know what are the things that needs to be done

1 Like
14

We just need to update the playbook in docs-fp-o with the new repository url, and that’s it.
We usually start with the staging environment first, to make sure everything is ok.
You can open a ticket on that same repo to track this kind of change.

3 Likes