Setup CI/CD?

[jaykrell]

We have no automated CI/CD. Someone please fix?

[ghost]

I'm working on CI/CD as one of my tasks (https://github.com/coder5506/cm3/actions/runs/1311614825 ). Currently I have automated build, install, test, and test reports working for Linux and MacOS, for both the C and integrated GCC backends.

I'm trying to get the LLVM backend working and not having a lot of luck. I'm working with LLVM 9 on both Linux and MacOS (because that is the oldest LLVM I can get without going to extraordinary measures) and, with some modifications, I am able to build and install the llvm9bindings and llvm9 packages. Having done this, the StAloneLlvm* backend modes will run, but fail, and the IntLlvm* and ExtLlvm* backend modes all segfault.

So I'm hoping somebody can tell me what the current status of the LLVM backend is. Is it expected to work? On what platforms? If it's too early to expect it to work in a CI/CD context, I'm happy to drop it, but if it's just user error I need to know so that I can continue to try.

Thanks!

[VictorMiasnikov]

} I'm working with LLVM 9

LLVM 10 is good variant too

} current status of the LLVM backend is. Is it expected to work? On what platforms?

On Windows x64 LLVM 10 and LLVM 9 backends can compile "Hello.exe" from examples folder

[ghost]

I was beginning to suspect it was Windows-only at the moment. I haven't yet setup CI/CD for Windows, though I hope to get to it soon. Thanks for your updated Windows builds.

[VictorMiasnikov]

} Thanks for your updated Windows builds.

You are welcome!

(

In fact I was public files in goal to help with CI/CD for Windows ( and "free Windows" ReactOs )
)

} I was beginning to suspect it was Windows-only at the moment.

I am not sure ;-( in fact "cm3 LLVM for Linux" may be can work with debugger, etc

} I haven't yet setup CI/CD for Windows, though I hope to get to it soon.

May be we can try "AppVeyor CI" ?

[ghost]

May be we can try "AppVeyor CI" ?

Maybe? Github claims to support Windows with their integrated CI, but I don't know how good it is.

The main reason the Windows CI isn't done yet is just unfamiliarity. I used to do a lot of Windows development from the late 80s into the early 2000s, but it's been at least 15 years now since I've even used a Windows machine.

I've found the Windows development images https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/ and I do hope to use your builds to bootstrap. Once I get that up and running I'll be in a better position to finish this part of the CI project.

I did not know about ReactOS, but I'll try it out once I've got the basics down.

[VictorMiasnikov]

(

about "AppVeyor CI" I wrote in "CM3 Maillist". I going to find direct URL to this message.
In any key, I wrote only one phrase: "I have idea: we can use A."

)

} I did not know about ReactOS, but I'll try it out once I've got the basics down.

We can temporary forgot about ReactOS

} I've found the Windows development images

It's good idea

[VictorMiasnikov]

(
Moved(?) from #763
)

}} Error: Resource not accessible by integration
}This error means that this patch is causing the tests to crash, so there is no test report to display.

I even known this tests:
e020: illegal recursive declaration
and
e019: illegal recursive declaration

[VictorMiasnikov]

I see:
fix Windows integration test · a28ce15 · GitHub

= =
fix Windows integration test
Unfortunately limited in a couple of ways.

We can't "buildship all" because that runs out of memory in the Windows CI
environment, so we "buildship min" and the builds are not as comprehensive as
on the other platforms (linux/mac).

Also the m3tests suite does not work on Windows. Each test is run as
"./pgm.exe" which Windows interprets as the command "." with the flag
"/pgm.exe", i.e., an error. (This is reproducible outside of the CI
environment.)
= =

c)

out of memory
^^^^^^^^^^^^ I don't have problems with 4Gb RAM in my local VM =} what is "Github Action VM" settings?..

d)
May be decrease 20 to 4 .. 2 ?
= =
****  PARALLEL BACK-END BUILD, M3_PARALLEL_BACK = 20
= =

z)

"./pgm.exe"
-- change --}
".\pgm.exe"

[ghost]

c) out of memory
^^^^^^^^^^^^ I don't have problems with 4Gb RAM in my local VM =} what is "Github Action VM" settings?..

It has 7GB. Barely enough to run Windows.

d) May be decrease 20 to 4 .. 2 ?
**** PARALLEL BACK-END BUILD, M3_PARALLEL_BACK = 20

I didn't think about that. I'll see if I can find that setting somewhere.

z)
"./pgm.exe"
-- change --}
".\pgm.exe"

I did think to try that, but I couldn't find where that can be changed, without breaking all the other platforms. I expect it will work on mingw, using bash instead of cmd, but I don't have the bash/VC++ environments playing well together yet.

[ghost]

No luck on the out-of-memory issue. The VM has 2 cores, so I set M3_PARALLEL_BACK = 3. What I get on Windows is first, klex fails on Calc.l because of a blank line in the file. Removing the blank line in Calc.l lets me progress to the out-of-memory error.

None of this happens when I build "by hand" in a Windows VM, only in the CI environment.

D:/a/cm3/cm3/caltech-parser/parserlib/kyacc/AMD64_NT/kyacc ../src\Calc.y -o CalcParse.i3 -t ../src\Calc.t -ti3 CalcTok.i3


***
*** runtime error:
***    NEW() was unable to allocate more memory.
***    file "../src/runtime/common/RuntimeError.m3", line 63
***

The issue with the blank line in Calc.l is mysterious. It's two consecutive linefeeds "\n\n", and somehow klex doesn't recognize it as a blank line? I could almost say, well it's Windows so it expects "\r\n\r\n"... but it works outside the CI.

[VictorMiasnikov]

*** runtime error:
***    NEW() was unable to allocate more memory.

We can see detail in
https://github.com/coder5506/cm3/runs/3962614682?check_suite_focus=true
?

P.S.
It looks like "no", because this
= =
'mklib' is not recognized as an internal or external command, operable program or batch file.
= =
is old known error.

P.P.S.
I start read this:
https://github.com/coder5506/cm3/runs/3962242650?check_suite_focus=true

--

[VictorMiasnikov]

...

[VictorMiasnikov]

Now I going to test

\scripts\dev\windows\RCC_upgradeCM3_All_AMD64_NT.cmd

with
VictorMiasnikov@6122403

I hope avoid this error:
= = =

------------------------------------------------------------------------------
 . . .

WARNING:  One or packages experienced a failure.  See result detail above.

ERROR LOG SUMMARY:
-----------------
WARNING:  Errors in package "caltech-parser\parserlib\parserlib\test_parserlib" for "-build"
---END-of-List---

 . . .
===END do-cm3===
...
===END RCC_upgradeCM3===

= = =

Done:

= = =

===END do-cm3===
...installing new cm3.exe as "D:\cm3\bin\cm3.exe" ...
        1 file(s) copied.
        1 file(s) copied.
 
========================================================================
Critical Mass Modula-3 version d5.11.4
  GitInfo: unknown
  last updated: 2021-10-07
  compiled: 2021-10-21 15:04:01
  configuration: D:\cm3\bin\cm3.cfg
  host: AMD64_NT
defaulting to native build: AMD64_NT
  target: AMD64_NT
 
========================================================================
===END RCC_upgradeCM3===
 
D:\cm3\scripts\dev\windows>

= = =

but cm3.cfg is "Big size style". I restore "small size" cm3.cfg from backup.

[VictorMiasnikov]

#766 (comment)

Please no more cmd.

I had written to @VictorMiasnikov privately about this. The good news, there will be no more cmd. The bad news, we'll get javascript instead. (I know, "stop, you're making it worse!")

It appears at this time that the only way I will be able to get the Windows CI functioning to the same level as the other platforms, will be basically to recreate the functionality of the various *.cmd, *.sh, and *.py scripts in javascript. Because while the existing scripts do work fine when I run them on the command-line, I'm unable to get any of them to work in the CI environment.

I will not be adding a fourth language to the scripts directory, it will be confined to the .github CI directory, and it will certainly be the minimum I can get away with because I'm no fan.

In the end if javascript does work for the CI and nothing else does (still an open question), you can decide if the working CI is worth the pollution.

[VictorMiasnikov]

...

[VictorMiasnikov]

issuecomment-950853096
#766 (comment)

What is wrong with Python in this context?

Can I use the JS on command line, with node and/or deno, "portably" (Mac, Windows, Linux at least, ideally FreeBSD, OpenBSD, NetBSD, Solaris, hypothetically AIX, HP-UX, VMS?.. but granted, just the first 3 is 99.999%, good enough).
Can the JavaScript write out .sh or other?

Aside: I recently was using OSF and Python worked well.

Is Typescript viable?
Typescript is one of my hypothetical favorate languages, not having used it: statically typed, runs in browser.

issuecomment-950854115
#766 (comment)

Also, if your scriptsdo have the functionality of the .sh/.py/.cmd I'd be ok with putting them right in scripts, no subdirectory.
I think the .sh should be deleted and .py moved up, really.
I regret creating the subdirectories there.

As long as they are actually usable on fairly normal command lines, again, like with node/deno on Mac, WIndows, Linux.
If they are actually CI specific they right keep them out.
If they only work on one or two of those systems, then still probably ok.

[VictorMiasnikov]

...

[VictorMiasnikov]

issuecomment-950865609
#766 (comment)

What is wrong with Python in this context?

Honestly, I don't know. Python does work interactively, on the command-line. In the CI environment... My best guess, and it is only a guess, is that the Windows/CI does not do a very good job at combining environments, and various bits are in cmd, powershell, python, and javascript. Maybe some bash. I'm going to try writing everything in javascript because it is the "native" language of Github's CI. I hope to cut out all the various layers as best I can, and work at just one level. I won't know if that actually succeeds until I've tried it, right now I only know that nothing else is working.

Can I use the JS on command line, with node and/or deno, "portably" (Mac, Windows, Linux at

For my initial experiment, the answer is "no" because I will be relying on certain github libraries that only function in the CI environment. If it works and there's interest, I don't see any obstacle to generalizing.

Is Typescript viable? Typescript is one of my hypothetical favorate languages, not having

Yup, I can do do typescript. It should work just as well in this context.

[VictorMiasnikov]

...

[VictorMiasnikov]

...

[VictorMiasnikov]

...

[ghost]

Quick status update on the CI for those who are following.

The problem with the Windows builds turned out not to be the Github CI environment, but just that our Python scripts are old and crufty. In particular, SetupEnvironment might be better named BreakEnvironment at this point. :) That's not to be critical, I've written enough such scripts in my time that I know how they come to be.

Anyway, as SetupEnvironment is doing more harm than good these days, I've started on some script updates that just avoid it entirely, and those are working great. I do have a working Typescript implementation, as discussed previously, but it doesn't seem necessary and Python still has much better platform support, so for now I'm shipping the Python version.

Right now we have working CI on Linux, MacOS, and Win32. Mingw is not working because I don't have a working Mingw build to start with, and I'm unable to create one because the old scripts don't work. I expect to add Mingw once I've finished cleaning up the "boot" and "make-dist" functionality.

Since @Pawlicker was kind enough to contribute a working Arm build, and CircleCI has Arm support, I'll try to get ARM64_LINUX build working on CircleCI when I have a chance.

Lastly, I did try speeding up build times by leaving out the GUI builds, but it didn't save much time and greatly reduced the scope of the CI, so for now they're still there. I do have plans to define a "headless" package set, but not urgently.

The plan right now is:

1. Fix the "boot" and "make-dist" scripts.
2. Get Mingw working.
3. Look into Arm CI.

[VictorMiasnikov]

} Win32

I.e. "both Win32 and Win64" ( as I see)

} working Mingw build to start with

Binary releases
cm3--AMD64_MINGW-d5.11.3-MINGW64(git-sdk-64@53940e
from
https://github.com/VictorMiasnikov/cm3/releases/tag/d5.11.3_8a842be
is good.

} old scripts don't work
It's possible.

If 8a842be is good as "source code" for build AMD64_MINGW by "boot1.py + boot2.py way" then I will prepare "reverse patch"

[ghost]

Thanks, I tried your Mingw build, but it apparently does not include this patch 17f0fdc and so cannot build current code.

If you have time to work on it, the required step are:

1. Rollback to bf48f02 or earlier
2. Cherry-pick the above commit 17f0fdc
3. Build the compiler
4. Roll forward to again to 7c767c9
5. Build the compiler
6. Make a distribution

Then I should be able to use that for Mingw CI. I couldn't do it because the make-dist script doesn't work for me on Windows.

[VictorMiasnikov]

It doesn't be a problem: I will prepare new 7c...c9  MinGW release 

…

01.11.2021, 20:12, "Eric Sessoms" ***@***.***>: Thanks, I tried your Mingw build, but it apparently does not include this patch 17f0fdc and so cannot build current code. If you have time to work on it, the required step are: Rollback to bf48f02 or earlier Cherry-pick the above commit 17f0fdc Build the compiler Roll forward to again to 7c767c9 Build the compiler Make a distribution Then I should be able to use that for Mingw CI. I couldn't do it because the make-dist script doesn't work for me on Windows.

[VictorMiasnikov]

Please see #772

      CM3RELEASE: https://github.com/VictorMiasnikov/cm3/releases/download/d15.11.4_5.11.4-ZZYYXX-20211101_22-02_66914fc
      CM3BUILD: cm3-min-AMD64_MINGW-d5.11.4-MINGW64.git-sdk-64@53940e3_and_.mingw-w64-x86_64-gcc-10.3.0-2.-2021-11-01_22-02__FIXed__by__VVM__2021-11-02_14-16__16bit__Unicode__AMD64_MINGW__Target__cm3-66914fc.7z

[ghost]

Trying it now.

[VictorMiasnikov]

Thank! I hope "all be good" ;-) 

…

02.11.2021, 18:36, "Eric Sessoms" ***@***.***>: Trying it now.

[ghost]

These builds are good. I wasn't quite able to finish the Mingw CI today, but it should get done tomorrow.

[VictorMiasnikov]

} These builds are good. Ok. Thank! } Mingw CI   Yes, thank, I see commit dede296 in "ci" branch, etc

…

03.11.2021, 02:25, "Eric Sessoms" ***@***.***>: These builds are good. I wasn't quite able to finish the Mingw CI today, but it should get done tomorrow.

[ghost]

I love it when a plan comes together. https://github.com/modula3/cm3/actions/runs/1416147775

That just leaves Arm, for now.

[VictorMiasnikov]

 03.11.2021, 13:33, "Eric Sessoms" ***@***.***>:  I love it when a plan comes together. >https://github.com/modula3/cm3/actions/runs/1416147775 That just leaves Arm, for now.

Yes: it's  a good news