search

c-blake / cligen

Nim library to infer/generate command-line-interfaces / option / argument parsing; Docs at
https://c-blake.github.io/cligen/
ISC License
501 stars 23 forks source link

Add CI testing workflow #152

Closed jiro4989 closed 4 years ago

c-blake commented 4 years ago

You aren't the first person to think this could be helpful, but you are the first to just do a PR to add it. :-)

The reality is that I almost always run my test.sh before I commit or at least before I git push to github. Anyone working on the main theme of the package could do the same. When I test locally I get an answer in a few seconds.

So, the only value this really adds is checking non-local platforms. Things currently tested do not vary by platform very much/at all, really, though that could change. I'm not saying "no", exactly, but let me think about whether we want this feature active. 2..5 minutes is kind of a long time. (I know, I know..The main Nim CI takes hours including queuing time...That slow delay/workflow is one reason I've never liked these auto-CI systems very much.)

jiro4989 commented 4 years ago

We can not know that he has tested code when someone create a new PR. Auto-CI system always tests the PR. We do not have to test his code. I think that it is one value.

And CI sets a green badge to commit-log of GitHub. It means that the repository is always testing code, and it guarantees the quality of repository. People that do not know the repository will feal relieved. I think that it is one value too.

c-blake commented 4 years ago

The github passers-by thing may have some subjective value, but honestly I get very, very few PRs on this repo.

kaushalmodi commented 4 years ago

@jiro4989 This is awesome! Can you also add auto docs generation using GitHub Workflow?

jiro4989 commented 4 years ago

Yes, I can do it. I will create a PR to generate API docs if you want it. @c-blake @kaushalmodi

kaushalmodi commented 4 years ago

@jiro4989 Thanks. And if I may add (if @c-blake approves), running the cligen tests on the choosenim update devel --latest would also be very helpful. That will test cligen against Nim devel HEAD. As there are chances that Nim HEAD can break cligen, failures on that should not report the entire CI as failed (is that possible?).

But at least that way, one can quickly check if cligen is working with devel and if an issue needs to be opened on the Nim repo.

kaushalmodi commented 4 years ago

@jiro4989 Also, doc generation has got much much better on devel. You need just nim doc --project .. and that generated search index, the index, docs of nested modules, everything. So while you add "devel --latest" to the matrix, using just that to generate docs would be helpful.

c-blake commented 4 years ago

I definitely think Nim HEAD is more relevant than any specific version. We even had that early release they pushed us into for some weird Nim HEAD CI problem (another strike against too much CI automation - it is definitely a mixed bag, as the saying goes). and I'm fine with auto doc gen, though that changes even less often. PR when you feel like it, @jiro4989.

jiro4989 commented 4 years ago

@kaushalmodi

As there are chances that Nim HEAD can break cligen, failures on that should not report the entire CI as failed (is that possible?).

Yes, It is possible. continue-on-error - GitHub Actions

@c-blake

I'm fine with auto doc gen, though that changes even less often. PR when you feel like it, @jiro4989.

Thank you. I will PR later.