On Thu, Mar 11, 2021 at 1:20 PM E. Madison Bray <erik.m.b...@gmail.com> wrote: > > On Thu, Mar 11, 2021 at 12:52 PM Dima Pasechnik <dimp...@gmail.com> wrote: > > > > On Thu, Mar 11, 2021 at 10:11 AM Dima Pasechnik <dimp...@gmail.com> wrote: > > > > > > On Wed, Mar 10, 2021 at 4:00 PM E. Madison Bray <erik.m.b...@gmail.com> > > > wrote: > > > > > > > > On Tue, Jan 12, 2021 at 11:33 PM tobia...@gmx.de <tobiasd...@gmx.de> > > > > wrote: > > > > > > > > > > > > > > > For what's worth, + 1 for migrating to github. > > > > > > > > > > The interface is cleaner, it has many more features and integrations, > > > > > and is more active which could attract more contributions. There are > > > > > a few scripts/tools that allow to migrate from trac to github. But > > > > > most of them are unmaintained for a few years already, so I'm not > > > > > sure if they still work (which should be taken as a sign that one > > > > > should migrate sooner than later). > > > > > > > > In 2019 Julian Rüth and I, with the help of some others, already put > > > > in some effort to set up an organization for SageMath on GitLab: > > > > https://gitlab.com/sagemath > > > > > > > > Between GitHub and GitLab, we felt that the latter would be more > > > > acceptable to the broader Sage community. We also implemented a bot > > > > that can mirror GitLab merge requests as Trac tickets, though it's > > > > been in need of troubleshooting for a while. > > > > > > > > This was also done before the advent of GitHub Actions, and the > > > > ability to provide custom CI runners for GitLab Pipelines seemed > > > > advantageous, since we could maintain our own fleet of runners, be it > > > > on Sage developers' personal machines (if they are generous enough to > > > > host them) or any conceivable constellation of cloud computing > > > > platforms. > > > > > > > > In practice this has gained little traction, in part due to lack of > > > > advertising. The GitLab Runner solution also proved a bit troublesome > > > > to maintain, as it required some constant attention to make sure there > > > > were always working runners available. I tried to keep that up for a > > > > while myself, but have had other obligations. > > > > > > I think it should be mentioned that GitLab has an analog of GitHub > > > Actions, > > > and the difference is that its runners may be self-hosted, or provided > > > by GitLab. > > > E.g. see https://gitlab.com/sagemath/dev/trac/-/pipelines/266731297 > > > > I just tried to switch to a "community" runner, and got an error which > > is probably > > obvious to people versed in Docker: > > > > https://gitlab.com/sagemath/dev/trac/-/jobs/1089520433 > > I think it might be because the Docker builds have been otherwise not > working for a while (due to lack of reliable runners). So a more > recent "build-from-clean" job is needed. These jobs are run when > develop/master are updated as well as on tags. Whereas > "built-from-latest" is run on branches for tickets. It tries to build > the branch on top of the "latest" Docker image e.g. for develop. But > the last one that built successfully is too old, and so trying to make > the diff between that ticket and the version of develop it's based on > fails. Hence the message: > > "Could not find commit fbca269f627bf6a8bc6f0a611ed7e26260ebc994 in > your local Git history. Please merge in the latest built develop > branch to fix this: git fetch trac && git merge > fbca269f627bf6a8bc6f0a611ed7e26260ebc994" > > But for the automated CI that's not a very useful message... > > I know Matthias has done some impressive things to get around GitHub > Actions' time limit on jobs by breaking the build up into "stages" > that can be split across multiple jobs. I see no reason that couldn't > work with GitLab as well. > > But it would still be better to have our own fleet of runners--they > would be faster, and we could test on more different custom hardware > configurations. The problem is that this is at a minimum a part-time > job...
Well looks like I need to correct the record a bit. Perhaps I've been a bit too sanguine about the state of the GitLab builds. In fact, the latest develop commit, 9.3beta8, built quite successfully: https://gitlab.com/sagemath/sage/-/pipelines/266734885 And it ran on one of the fleet of runners I've been maintaining here at Paris-Saclay, which I haven't touched in months. So I guess it's still working after all ^^; Ever since I set this up I had been having a problem with runners randomly erroring out, and not being deleted correctly when they do. I have tried many times to fix it to no avail, and I kind of gave up for a while. I assumed eventually this caused things to grind to a halt, but apparently not. Knowing that it's still working at least somewhat gives me motivation to try again to investigate the problem with the erroring runners and see if it can't be fixed. Maybe an upgrade of the gitlab-runner controller is in order... -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAOTD34auLjXwVGxA3fVHO1yoK-SSSbxQGki79_WijOD9Xru3gQ%40mail.gmail.com.
