GitHub Action setup

[jansorg]

Adds CI using GitHub Actions.

It fixes the failing tests, most notably 'bug-test-log', which compared unstable highlighting of Pygments. With this PR, the highlighted lines are stripped before comparing against the .right file.

[jansorg]

@rocky This is work-in-progress to add a basic GitHub Actions workflow.
When I checked the log, I noticed this: https://github.com/rocky/bashdb/actions/runs/7887294680/job/21522202111#step:5:90
The same log is apparently printed on CircleCI, too.

That comes from here and seems to be a hard-coded path. Can you tell if this is intentional or if this should be fixed?
https://github.com/rocky/bashdb/blob/49cb34c62a15c234af6a0f18906c3d2a39d22dcf/test/unit/test-cmd-info-variables.sh.in#L35-L38

There's one or two other test errors, but I haven't checked them yet.

[rocky]

@rocky This is work-in-progress to add a basic GitHub Actions workflow. When I checked the log, I noticed this: https://github.com/rocky/bashdb/actions/runs/7887294680/job/21522202111#step:5:90 The same log is apparently printed on CircleCI, too.

That comes from here and seems to be a hard-coded path. Can you tell if this is intentional or if this should be fixed?

https://github.com/rocky/bashdb/blob/49cb34c62a15c234af6a0f18906c3d2a39d22dcf/test/unit/test-cmd-info-variables.sh.in#L35-L38

This was not intentional. I hope #16 will address this.

How this kind of things happens... (you can skip this if you are not interested)...

I start out with scripts with hard-coded paths and those get turned into ".in" files after going over and generalizing them. Here I missed a place, or subsequently made a change in test-cmd-info-variables.sh and a specification didn't get turned back into its generic form.

[jansorg]

Note: CircleCI is showing the same errors, but the job doesn't fail (I have no experience with CircleCI): https://app.circleci.com/pipelines/github/rocky/bashdb/36/workflows/5f1aad78-c289-43b0-88cb-0ad89fa8e154/jobs/24?invite=true#step-108-10074_61

[rocky]

Note: CircleCI is showing the same errors, but the job doesn't fail (I have no experience with CircleCI): https://app.circleci.com/pipelines/github/rocky/bashdb/36/workflows/5f1aad78-c289-43b0-88cb-0ad89fa8e154/jobs/24?invite=true#step-108-10074_61

One of cool things that CircleCI provides is that you can run CI with ssh enabled and look around at the environment or rerun. (Another great thing about CircleCI is that is generally very fast, much faster than workflows).

I'll look into the failure when I get a chance to see what's up when I get a chance.

[jansorg]

Thanks!
I think I know what's going on.
When I run just test-cmd-info-variables.sh then it's passing. But executed with all other tests present it's failing.
When I remove . ${abs_top_srcdir}init/vars.sh from test-action.sh, then test-cmd-info-variables.sh is passing (if only these test*.sh files are present).
The Makefile is not isolating the tests, so side-effects of one test could break another. IMHO executing tests in isolation would fix this.

[rocky]

Thanks! I think I know what's going on. When I run just test-cmd-info-variables.sh then it's passing. But executed with all other tests present it's failing. When I remove . ${abs_top_srcdir}init/vars.sh from test-action.sh, then test-cmd-info-variables.sh is passing (if only these test*.sh files are present). The Makefile is not isolating the tests, so side-effects of one test could break another. IMHO executing tests in isolation would fix thi

Great work! Yes, not isolating tests is bad. If you have ideas on how to isolate better, please do!

[jansorg]

I changed tests/unit/Makefile.am to use the automake parallel test harness with a custom LOG_COMPILER to execute the *.sh tests with shunit2 as before.
This is working well so far, although I'm not sure if my Automake changes are good.

The only remaining test failure is integration/test-bug-loc. As far as I understand it's failing because pygmentize is different to what's usually used to run the tests. The GitHub Actions Linux runner has 2.11.2.
https://github.com/rocky/bashdb/actions/runs/7892396763/job/21538781795#step:5:5

[rocky]

I changed tests/unit/Makefile.am to use the automake parallel test harness with a custom LOG_COMPILER to execute the *.sh tests with shunit2 as before. This is working well so far, although I'm not sure if my Automake changes are good.

Many thanks.

The only remaining test failure is integration/test-bug-loc. As far as I understand it's failing because pygmentize is different to what's usually used to run the tests. The GitHub Actions Linux runner has 2.11.2. https://github.com/rocky/bashdb/actions/runs/7892396763/job/21538781795#step:5:5

We should be turning off pygmentize in the tests. It makes testing way too fragile. One way to do this is possibly to remove pygmentize altogether in testing environments.

Another way is to not use Pygmentize if some environment variable is set. All CI system I know about set environment variable CI .

(I had meant to mention this with respect to a couple of your PRs as well.)

[jansorg]

@rocky I think it's ready now and I'd be glad for your review.
It's passing-j3 to make to keep the runtime low (< 1min), but it's not really needed if you don't like it.

AFAIK most tests already have highlighting turned off. But test-bug-loc tests a bug related to highlighting, so we should keep it, I think. I made a change to strip the highlighted lines from the files before comparing them.

[rocky]

Excellent! Many good changes here. Let's merge and iterate -

I will apply this to 5.1 and see if there is stuff from this branch that can be ported to zshdb.

[rocky]

@rocky I think it's ready now and I'd be glad for your review. It's passing-j3 to make to keep the runtime low (< 1min), but it's not really needed if you don't like it.

AFAIK most tests already have highlighting turned off. But test-bug-loc tests a bug related to highlighting, so we should keep it, I think. I made a change to strip the highlighted lines from the files before comparing them.

-j3 is fine for now. Actually, faster CI is always appreciated. If it needs to change in the future, we can do that.