Post B6iOAPwsr6LDnXyzLc by jenesuispersonne@piaille.fr
(DIR) More posts by jenesuispersonne@piaille.fr
(DIR) Post #B6iHJL4ldty3c1ye92 by azonenberg@ioc.exchange
0 likes, 0 repeats
Happy CI!I pulled the trigger and cut over completely, we are no longer building with GitHub Actions at all.Clean build with 45-74 warnings depending on platform, no asan/ubsan reports on the (admittedly limited) test suite, no static analysis errors, and 210 static analysis warnings - which while not ideal, is much better than the several thousand we had at the start.This means there is now a window in which pull requests don't have CI checks (since we only run the webhook on pushes to branches in the upstream repo) but I am planning to add a web form that devs can use to request a one-off build from a fork before merging the PR. Hopefully will get to that this weekend.https://dashboard.ngscopeclient.org/index.php?project=ngscopeclient
(DIR) Post #B6iHjAEiZADHWVwhQe by azonenberg@ioc.exchange
0 likes, 0 repeats
There is also currently no pretty green check in the GitHub web UI, but given the ongoing meltdowns I'm starting to think about migrating the project elsewhere eventually (although this will be a major undertaking given the complex submodule structure and many linked issues). So I don't want to put any more work than necessary into GH integration.The dashboard is there, devs can find it, it's good enough.
(DIR) Post #B6iO1KAWyY8fGY1vJg by jenesuispersonne@piaille.fr
0 likes, 0 repeats
@azonenberg You still have imgui and imgui-node-editor linked as absolute sub-modules, if you pass them as relative it will be a little easier.But what to make for the 3 external ones?Won't they also move from GH?
(DIR) Post #B6iO6D4InoC4gyRjAu by azonenberg@ioc.exchange
0 likes, 0 repeats
@jenesuispersonne huh i thought they were relative. I should fix that at some point
(DIR) Post #B6iOAPwsr6LDnXyzLc by jenesuispersonne@piaille.fr
0 likes, 0 repeats
@azonenberg I just pulled the repo and looked at gitmodules file.
(DIR) Post #B6iOBnVuj7rrAo1fFY by azonenberg@ioc.exchange
0 likes, 0 repeats
@jenesuispersonne external deps (i.e. stuff we didn't fork) I'm not too worried about. It's mostly just the hassle of module transitioning.I'm wondering about a bottom up approach moving like logtools and xptools first as a pilot
(DIR) Post #B6iOFiOBip4eRDHQRc by azonenberg@ioc.exchange
0 likes, 0 repeats
@jenesuispersonne anyway the ci still needs more work, then shipping an 0.2 release, before any other major infrastructure shifts
(DIR) Post #B6iOL2qz3yBjM5I58y by azonenberg@ioc.exchange
0 likes, 0 repeats
@jenesuispersonne and there is a ton of ongoing backend refactoring and cleanup to enable future stability and feature dev work to balance with all this
(DIR) Post #B6iONZDjh752Jp8SGW by jenesuispersonne@piaille.fr
0 likes, 0 repeats
@azonenberg Moving all relatively linked repositories is easier (no change to do in main repo) if done in one move.
(DIR) Post #B6iOT5TrBDBZorJ9sG by azonenberg@ioc.exchange
0 likes, 0 repeats
@jenesuispersonne yes i would likely temporarily make the links absolute during the switchover period
(DIR) Post #B6iOyPtXKXd66sG5WC by jenesuispersonne@piaille.fr
0 likes, 0 repeats
@azonenberg I don't think you especially need to do it.If I understand well, you will move all your repos from GH, doing all in one batch then try a full rebuild of everything from new repo will work if you have relative link to other modules (and if absolutely linked modules are in public repos).In a past company I work for, we did it to move from internal git server to private GH repos.
(DIR) Post #B6iP2UDRCtHafZVXWa by azonenberg@ioc.exchange
0 likes, 0 repeats
@jenesuispersonne the repo isn't the issue it's all the tickets and metadata
(DIR) Post #B6iP6QDC2G4FPTGn1E by azonenberg@ioc.exchange
0 likes, 0 repeats
@jenesuispersonne including things like "fixes #123" commit messages that I have seen break things during merges and migrations closing the wrong ticket etc
(DIR) Post #B6iP9WG012OZ1m3k36 by azonenberg@ioc.exchange
0 likes, 0 repeats
@jenesuispersonne moving the *code* is the easiest part
(DIR) Post #B6iQI33651R106egYy by jenesuispersonne@piaille.fr
0 likes, 0 repeats
@azonenberg You're right, at the time we didn't use GH for ticket management.
(DIR) Post #B6iQPL47Uep6uAbsuW by azonenberg@ioc.exchange
0 likes, 0 repeats
@jenesuispersonne you want fun try flattening a parent and submodule into one repo while not borking all the references to issue numbers
(DIR) Post #B6iR0ak8AROaF71XSi by azonenberg@ioc.exchange
0 likes, 0 repeats
@jenesuispersonne backstory: during the early phases of the transition from internal svn monorepo for all of my projects to public gh repo for libscopehal and scopehal-apps, the main project build system was "splash", an in house google-blaze-like platform for distributed builds, caching, etc.But I knew nobody else would be able to use that, so I made a "parallel construction" CMake build chain for other people to use in a scopehal-cmake repo that included scopehal and scopehal-apps as submodules..Over time as Splash bitrotted after I graduated, the CMake build system became the one and only, and we merged scopehal-cmake into scopehal-apps.Cleaning up all of the accidentally-closed issues from the merge took days. And there was a lot less history than there is now.
(DIR) Post #B6iTfn6xHtGoNoTNz6 by azonenberg@ioc.exchange
0 likes, 0 repeats
@jenesuispersonne anyway the first things i would migrate would be the free-standing repos like the CI scripts and the project website that have no deps in or out and very few open tickets