Various problems encountered after a 4.6 -> 4.39 upgrade.

[sorpigal]

Issue

Impacted version: 4.39.0

Deployment mode: I am accessing gitbucket directly (executed the .war on a Linux box, connected to :8080 on that box).

Problem description:

I am involved with a project that has been using gitbucket 4.6 since it was the latest version (actually longer, we upgraded from 3.x to 4.6 years ago). Recently we upgraded to 4.39.0 and had major problems.

I don't have any of the logs available to me now and cannot recover any of the error messages. However, the errors we got looked identical to those seen in the last comment on #2700 so that should give you an idea (the COMMIT_COMMENT table was missing).

Upgrade steps were:

• Export a backup of the database from within gitbucket, creating a .sql file
• Stop existing gitbucket process
• rm the gitbucket symlink pointing to gitbucket.war at version 4.6
• add a symlink in the same place pointing at gitbucket.war at version 4.39.0
• exec the new gitbucket

At this point we got an error in the gitbucket log and all pages showed as 404 or worse. I tried stopping the process and restarting under 4.6, but that died with the same error in the log.

I wanted to try importing the .sql file but the UI wouldn't load to allow it. So, I stopped the process and moved the H2 .db files out of the way (into a backup location, even though they're probably junk now), and started 4.39.0 with no existing DB. It came up OK with an empty instance.

I logged in as root and tried to import the .sql file, but it's 80MiB and the process apparently failed without importing anything. Fortunately this version has the built in SQL viewer so I could inspect the DB (that's how I confirmed nothing actually imported).

We still had the clean export so we begin cutting and pasting insert statements from it a chunk at a time into the SQL query tool. We brought up the liquibase instructions for every version between 4.6 and present and attempted to apply the equivalent transformations whenever schemas changed. Eventually I scripted much of the imports using curl on the command line, but the whole process took >6 hours to completely recover.

At the end we have a working instance, but it's not completely working. I'm not sure to what degree the problems I am about to report are caused by the unusual upgrade process/failures above. I don't see how they could be related, but the whole story might be important, so there it is.

Now that we're on the new version I am noticing some UI regressions:

• There is no way to add a comment on the Conversation tab of a pull request. I can still comment on specific lines of change and have it appear on the Conversation tab and edit the comment there, but I can't add a new comment not attached to specific lines of change. Old pull requests that had such comments still display them.
• The inline "reply" option exists for comments viewed in the diff view, but the same comments on the Conversation tab have no reply UI.
• If a comment is added on a line and then a force push changes the line and another comment is added to the new line, then when you view the comments from the Conversation tab the second comment chronologically is listed first, then the older one below it. This makes it look like they occurred in the opposite order.
• In 4.6 when you clicked the Merge Pull Request button it would transform into a confirm button appearing in the same place, so two clicks in a row would perform a merge. In the current version the confirm button has moved to the opposite side of the screen so you must click, move the mouse, and click again--it's less convenient. What's worse, there is now a drop-down button that appears under the mouse after clicking the Merge Pull Request button and in its default state it has the label "Merge commit" which sort of looks like it's the confirm button if you're not paying close attention. This has tripped me up quite a few times and I wish it weren't this way.
• I don't see any way to close a pull request from the PR page itself, only from the $repo/pulls page.
• The PR page shows no UI for changing a draft to "ready"--the ready for review button does not appear. Inspecting the page we can see that there is JS for it, as well as for the Comment and Close buttons, but no HTML shows up.
• The side bar in 4.6 had a link to the $repo/pulls page and also issues, and other pages. In 4.39.0 I see only Files, Branches, Releases, and Settings on the sidebar. From screenshots I see on the internet I surmise that there is some way to make more things appear, but I don't see anything saying how.

I am perfectly happy to make one issue for each of the above items, but I suspect that most or all of them may actually be due to something having gone haywire with the data import process. Please do let me know if any are true issues that should have dedicated issue numbers.

EDIT: An embarrassing update on some of the above: after a week of trouble I opened this issue, then the next day found an option in the per-repo Settings page that controls the visibility of all of the sidebar links and the missing buttons on the PR page. All of the related bullets above have been struck out to indicate their invalidity. I can only presume that something in the wonky "upgrade" process failed to set the right flags in the repo tables that should have been set on upgrade rendering them effectively false, turning off PRs and all. (Minor note: even though PRs will disabled this way I could still make them by going to the direct URL for them; in this project we have a command line tool to launch the browser at the right URL so we never noticed the missing option).

[takezoe]

Hmm... Sorry for trouble in upgrading GitBucket. I would recommend upgrading GitBucket versions one by one if behind is very large like your situation. Of course, backup before upgrading is mandatory.

Anyway, thank you for your feedback. I will take a look at them one by one if those issues happen on the latest version.

[takezoe]

Regarding this point,

In 4.6 when you clicked the Merge Pull Request button it would transform into a confirm button appearing in the same place, so two clicks in a row would perform a merge. In the current version the confirm button has moved to the opposite side of the screen so you must click, move the mouse, and click again--it's less convenient. What's worse, there is now a drop-down button that appears under the mouse after clicking the Merge Pull Request button and in its default state it has the label "Merge commit" which sort of looks like it's the confirm button if you're not paying close attention. This has tripped me up quite a few times and I wish it weren't this way.

• Basically, buttons that execute something should be located to the right bottom of the form
• At first, I thought "Confirm merge" button can be pulldown + button like "Comment" button, however, merge strategy is really important so I thought it's better to be an independent pulldown.

Since I'm not a UI specialist, it would be great if you can propose what it should be.

[sorpigal]

I'm not a UI specialist either, but I sometimes play one at work for lack of anything better. I think the pull down button concept would work well here, but if all you did was move the left-aligned initial Merge button the be right-aligned it would return to being a simple two-click operation without a mouse move.

E.g.

Or do both and use a combo button:

The strategy is important, but it's not something one changes every time. It's the more rare exception.

If you can't figure out something you can be happy with I'd just leave it as-is. This is something that I can get used to even if I don't think it's optimal for me.

I'll end with an aside I should have had in my original comment: it may sound like a complaint, but I actually really like gitbucket and recommend it to people constantly. It's the easiest way to go from zero-to-git-web-ui anywhere and is good enough that many people won't need anything else.

[takezoe]

Thank you! Locating the initial "Merge pull request" button at right side looks good idea. It's align with our UI policy and minimize move of pointer.

[takezoe]

I think pull request UI will be improved by #3417. Remaining things are regarding comments in diff view:

• The inline "reply" option exists for comments viewed in the diff view, but the same comments on the Conversation tab have no reply UI.
• If a comment is added on a line and then a force push changes the line and another comment is added to the new line, then when you view the comments from the Conversation tab the second comment chronologically is listed first, then the older one below it. This makes it look like they occurred in the opposite order.