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

Mirror issues, PRs, and wiki pages #5

Open
Brycey92 opened this issue Mar 4, 2024 · 3 comments
Open

Mirror issues, PRs, and wiki pages #5

Brycey92 opened this issue Mar 4, 2024 · 3 comments

Comments

@Brycey92
Copy link

Brycey92 commented Mar 4, 2024

Large amounts of critical information can be stored in repositories' issues, PRs, and wiki pages. From what I've heard, Forgejo and Gitea can mirror these if one uses their importers on single repositories at a time.

It would be phenomenal if this script could trigger Forgejo/Gitea to mirror these, or if it could achieve mirrors of these in any other way.

@maxkratz
Copy link
Owner

maxkratz commented Mar 5, 2024

Hi @Brycey92!

I agree, it would be awesome if the script could achieve mirrors with issues, PRs, etc.

I've seen that you forked this repository and created a few branches. Are you actively working on this feature and are you planning on providing a PR?

@Brycey92
Copy link
Author

Brycey92 commented Mar 5, 2024

Hi!

I've started work on this feature, but it looks like Gitea itself doesn't support scheduled pull mirroring at the same time as importing/mirroring labels, issues, PRs, releases, or milestones. I can, however, add scheduled mirroring of LFS data, and I can check the box for wikis, but Gitea doesn't make it clear whether that's a one-time import of the wiki or a scheduled mirror. More testing for this is required.

The best alternative I've come up with so far is to add an option to the script like --metadata which creates Gitea orgs like ${gittea_organization}_metadata. These orgs would have pull mirroring disabled, but would have the aforementioned metadata (and wikis?) imported. Being separate orgs allows them to be wiped and re-imported periodically with the two scripts in this repo, without affecting existing pull mirrored orgs and repos. I may want to make the script smart enough to create ..._metadata2 orgs, then import, then delete only those ..._metadata orgs that were imported successfully, then rename ..._metadata2 orgs to remove the 2.

I have a set of untested changes in feature/metadata that implements the first half of this, but before testing and finishing that, I'm currently trying to get --mode user to accept arbitrary users to --user. Presently, the script just mirrors the authenticated user's repos no matter what the value of --user is.

@maxkratz
Copy link
Owner

The best alternative I've come up with so far is to add an option to the script like --metadata which creates Gitea orgs like ${gittea_organization}_metadata. These orgs would have pull mirroring disabled, but would have the aforementioned metadata (and wikis?) imported. Being separate orgs allows them to be wiped and re-imported periodically with the two scripts in this repo, without affecting existing pull mirrored orgs and repos. I may want to make the script smart enough to create ..._metadata2 orgs, then import, then delete only those ..._metadata orgs that were imported successfully, then rename ..._metadata2 orgs to remove the 2.

That sounds like a nice workaround for me. I think we need so much further code for this that it probably makes sense to create another script just for the metadata mirroring.

I have a set of untested changes in feature/metadata that implements the first half of this, but before testing and finishing that, I'm currently trying to get --mode user to accept arbitrary users to --user. Presently, the script just mirrors the authenticated user's repos no matter what the value of --user is.

You are correct. I've added a few comments to your PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants