Erik, did you stop the Orsay runners for gitlab ? It seems that the docker build there for 9.3.b9 is stuck by lack of runners.
https://gitlab.com/sagemath/sage/-/pipelines Frédéric Le jeudi 11 mars 2021 à 13:25:52 UTC+1, erik....@gmail.com a écrit : > On Thu, Mar 11, 2021 at 1:20 PM E. Madison Bray <erik....@gmail.com> > wrote: > > > > On Thu, Mar 11, 2021 at 12:52 PM Dima Pasechnik <dim...@gmail.com> > wrote: > > > > > > On Thu, Mar 11, 2021 at 10:11 AM Dima Pasechnik <dim...@gmail.com> > wrote: > > > > > > > > On Wed, Mar 10, 2021 at 4:00 PM E. Madison Bray <erik....@gmail.com> > wrote: > > > > > > > > > > On Tue, Jan 12, 2021 at 11:33 PM tobia...@gmx.de <tobia...@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/e954b177-351d-41b0-b0c2-48aa7108583fn%40googlegroups.com.
