Probably alias it to "master" somehow.
Description
Details
Project | Branch | Lines +/- | Subject | |
---|---|---|---|---|
labs/libraryupgrader/config | master | +4 -4 | "master" -> "main" | |
labs/libraryupgrader | master | +118 -45 | Support "main" branch |
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Open | None | T288685 Establish active/active multi-dc support for Toolhub | |||
Resolved | bd808 | T115650 Create an authoritative and well promoted catalog of Wikimedia tools | |||
Resolved | bd808 | T271483 Complete and announce initial production deployment of Toolhub | |||
Resolved | Legoktm | T279741 Integrate with LibUp | |||
Resolved | Legoktm | T273237 LibUp needs to handle "main" branches nicely |
Event Timeline
Basically we want "main" branches to appear as "master" in the UI, but all Git operations need to be done against "main".
The main place this is an issue is in the repositories.branch column. I think we should add a second column like repositories.git_branch, which has the *real* branch used in Git for all those operations. When creating/updating repositories rows, .branch will normalize "main" to "master".
Change 690922 had a related patch set uploaded (by Legoktm; author: Legoktm):
[labs/libraryupgrader@master] Support "main" branch
Change 690922 merged by jenkins-bot:
[labs/libraryupgrader@master] Support "main" branch
So...I messed up on one part, and that was instead of updating the existing "master" rows, it deleted them and created new "main" ones. Which means we lost all the dependencies, vulnerabilities, and most importantly logs of all "master" repos... sorry about that :/
Change 691554 had a related patch set uploaded (by Legoktm; author: Legoktm):
[labs/libraryupgrader/config@master] "master" -> "main"
Change 691554 merged by jenkins-bot:
[labs/libraryupgrader/config@master] "master" -> "main"
It could be a chance to start fresh ;-) Loosing data which could be generated is not a problem for me.
But the logs are linked from many places :-(
But the logs are linked from many places :-(
Exactly :/
In the old log system they were standalone HTML files, I would just delete them whenever we got low on disk space. Now they're all interconnected in the database, which means whenever the Repository object is deleted, the logs are too. So if the repository is archived, it'll get deleted. When REL1_31 is removed in a few months, all those logs will get deleted. Overall I think this is fine, and similar to the CI logs which expire after a few weeks. BUT there are some times we do want to keep specific logs for longer. One option could be to have a button that turns the log into a Phabricator paste (since we have straightforward Phab access with @LibUp-bot)?