issue migrations

[fadedhero]

First off, thanks for this library!

Just a suggestion, if possible: When creating issues, you should just count the number of the issue created to then assign the right comments, and not actually send a request to create the issue itself.
Since githubs api is really sensitive when creating issues, because it sends notifications aswell.
If you have a repository with over 100 Issues you will encounter "secondary rate limits".

Read here: https://docs.github.com/en/rest/guides/best-practices-for-integrators#dealing-with-secondary-rate-limits

Cheers

[fadedhero]

createIssueComments has a line where you mention the user, who the comment is orginally from.

You could do similar with the description of an issue and use issue.user to get the original author of the issue.

[sebj54]

Hey there! Thank your for your interest in this library :)

I didn't understand your point here:

When creating issues, you should just count the number of the issue created to then assign the right comments, and not actually send a request to create the issue itself.

Actually, this goal of this script is to migrate issues so I don't think it will be relevant to not create them.

I think the "secondary rate limits" were already in place when I built this script and I did not experience any limit because all requests are authenticated and serialized (as suggested in your link).

Unfortunately, I no longer have a Gogs instance so I won't be able to test any modification of this script. But if you'd like, you can do any modification, test it and then submit a PR. I can assist you if you need help :)

[fadedhero]

Ah sorry I see myself I wasnt pretty clear about that.
My requests are all authenticated and serialized, even put a sleep method for 2-3seconds before each issue/comment request, but still git stops my requests after around 120.
This is the line I was talking about:

else {
    issuesInOrder.push({
        title: `Missing PR #${number}`,
        body: 'This issue has been created to keep issues in the right order after a migration from Gogs.',
        number,
        state: 'closed',
    })
}

Its neccessary because gogs is creating issues for every pull request and deleting them afterwards so the numbers are not in order. You actually create an issue and make a post request so the number of issue is correct.
I commented this line out and tweaked it so it does not send additional requests just to keep the number line in order but start with #1 for the new issues and keep on counting +1.

My workaround was to leave out additional issues and add a new_number, which then I can refer to in the POST request so the comments find their right issue:

async listAllRepoIssuesInOrder(repo) {
    const issues = await gogs.listAllRepoIssues(repo)
    const issuesInOrder = []
    let i = 0
    let number = 0

    while (i < issues.length) {
        number += 1
        const issue = issues[i]
        
        if (issue.number === number) {
            issuesInOrder.push(issue)
            i += 1
            issue.new_number = i
        }
        // else {
        //     issuesInOrder.push({
        //         title: `Missing PR #${number}`,
        //         body: 'This issue has been created to keep issues in the right order after a migration from Gogs.',
        //         number,
        //         state: 'closed',
        //     })
        // }
    }

    return issuesInOrder
}

const { data } = await octokit.request(`POST /repos/${full_name}/issues/${issue.new_number}/comments`, payload)

[fadedhero]

But I can imagine that its not worth to implement this, if people want it the other way.
I think everyone can just be happy to fork your library and tweak it as they wish :)
So this is not a real issue and can be closed! Thanks anyways!

[sebj54]

Ok I see the problem you tried to fix now. Maybe I didn't have enough issues to be limited by GitHub.

I added these "placeholder issues" so my issues had the same number on GitHub and Gogs because I usually close issues from a commit. I had to insert blank issues so my commits were still referring to the correct issue.

Like you said, I won't fix it for now but I will let the issue open so people with the same problem will be able to use your workaround.

Thank you for reporting the problem anyway 😃