Probably alias it to "master" somehow.
Description
Description
Details
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 | T271483 Prepare for production deployment of Toolhub | |||
| Resolved | Legoktm | T279741 Integrate with LibUp | |||
| Resolved | Legoktm | T273237 LibUp needs to handle "main" branches nicely |
Event Timeline
Comment Actions
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".
Comment Actions
Change 690922 had a related patch set uploaded (by Legoktm; author: Legoktm):
[labs/libraryupgrader@master] Support "main" branch
Comment Actions
Change 690922 merged by jenkins-bot:
[labs/libraryupgrader@master] Support "main" branch
Comment Actions
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 :/
Comment Actions
Change 691554 had a related patch set uploaded (by Legoktm; author: Legoktm):
[labs/libraryupgrader/config@master] "master" -> "main"
Comment Actions
Change 691554 merged by jenkins-bot:
[labs/libraryupgrader/config@master] "master" -> "main"
Comment Actions
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 :-(
Comment Actions
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)?