CI and debug

[phidebian]

HI All,

Sounds like I got to present myself before posting my 1st post, dunno what to say, I am a shell enthusiast, when I bump into bug/pb in a shell I tend to fix it. I hacked a lot ksh88 for my professional needs (way back), but nowaday I peek/poke into ksh93 and bash. I excluded zsh that I don't like for various reasons. If you need more let me know.

My questions :-)

Is there a docco somewhere about the CI thing (I am a begginer here), I am curious to discover if I can try my PR on many os/arch, so far I only check my build node (ubuntu LTS 22.04 x86_64).

Is there a docco about setting the debug mode, or various debug technics, so far I only use the -g compile and GDB, but may be there are other conditional compile flags to use in order to trace or profile some run.

And finnaly how to use bin/package (or something else) to do a unitary test, say variable.sh alone, I did my own hack for that, in my local build env, but may be you have some 'official' technics.

[hyenias]

Welcome, @phidebian. In regards to running the regression tests, see bin/shtests. Typically, after running bin/package make I run bin/shtests to run all the regression tests. As noted on this site's front page see bin/shtests --man for more detail. For example, if one wants to run all the variables.sh tests (-p, -u, and -c), use bin/shtests variables. If one wants to perform just the utf8 variables.sh test use bin/shtests -u variables.

I have been directed to utilize bin/package make CCFLAGS='-O0 -g' to create a debug build.

[phidebian]

@hyenias, thanx,

Ha got it :)

Yes I go the debug build ok, though I use -O0 -g3 (get macro's)

I missed bin/shtest, I was doing ./bin/package test and didn't spotted the reference to bin/shtest on the front page, bin/package test don't mention -c -d -p etc...

I was also asking about other debug/trace technics, but reading other discussions I got pointers...

I am curious about CI as well, I am not familiar with, I got the impression that VM of all sort are available on github and then could test (run the test suite) on those VM to verify I am not breaking something elsewhere.

[JohnoKing]

Currently, the CI tests are only run on Linux. When the CI builds were first introduced (commit 85165ee) it tested builds for both macOS and Linux, but the macOS CI had to be dropped because the GitHub runners for macOS were broken (commit 1463236).

[hyenias]

Excellent detail.

For some insights into CI, see the following as it just might raise your awareness of CI enough to find the answers you seek:

• https://docs.github.com/en/actions/automating-builds-and-tests/about-continuous-integration
• https://github.com/features/actions

Observation: See the repo's "Actions" tab. Additionally, my fork of this repo runs its defined CI checks as noted by a little green check or red x on the commit line summary. Perhaps when you push a PR besides making a branch a CI check will run. Clicking on the Actions tab and looking under the 3 dots inside the workflow file was very enlightening.

[phidebian]

Thank you both, I was on the path, I did dare strike the action button and started to discover thing.
I discovered that CI can be run with both remote (github) VM's and local machine, I guess this is the way you test some more exotic config like HPUX :)

I will look at this doccos you pointed out.

[McDutchie]

I am a simple man with simple methods. To test ksh on any particular system, I log in to it, compile ksh, and run bin/package test or bin/shtests.

[phidebian]

Ha ok, when I saw some post about macos, windows, solaris, AIX, may be HPUX, I was kind scared, I don't have access to any of those, so I discover reading some trail that CI existed and thought may be you were using that...

Ok I go with local testing only, but I only have a laptop with debian/ubuntu (dual boot) x64 so my tests coverage is pretty limited.