CI: xut #53

zenobit commented 2025年11月28日 08:02:47 +01:00

Playing with Forgejo/Codeberg actions for first time...

To test if xut works as expected

For PR with shfmt/shellcheck repair needs generated Personal Access Token named FORGEJO_TOKEN
In User settings -> Applications -> button Generate token
added to User settings -> Actions -> Secrets

Commit Auto-fix

!53 (commit b693008918)
Done by this CI to test if PRs are working

Playing with Forgejo/Codeberg actions for first time... #### To test if **xut** works as expected For PR with shfmt/shellcheck repair needs generated Personal Access Token named `FORGEJO_TOKEN` In `User settings` -> `Applications` -> button `Generate token` added to `User settings` -> `Actions` -> `Secrets` #### Commit Auto-fix https://codeberg.org/mobinmob/xut/pulls/53/commits/b6930089185c43eadd4940aec5e34e50c4fdcc07 Done by this **CI** to test if PRs are working

AngMits commented 2025年11月29日 10:13:43 +01:00

Well, this is very interesting, and I have been working with something similar using a mirror on GitHub. Please have a look at the following comments, as I'm interested in moving everything here (if that would be possible).

1. Where is the runner hosted? I know I have something I can contribute as a Forgejo runner, but judging from the code, I assume this runs on GitHub infrastructure. This comes with a variety of concerns, but the most important one is availability for open-source projects. Yes, scale is of no concern at the moment, but even a playground can get... well... busy, especially during trial-and-error development, which means that with a little effort, the setup will hit its limits and stop working.
2. How was this code generated? There are a lot of repeated steps that should be abstracted somehow to separate the logic between "CI" and "code being run" (especially those EOF lines are completely redundant, and can be handled in 3 different ways). In general, I feel it is quite cleaner to have the YAML be a caller for other items, instead of dumping code inside the .yml file, for maintainability purposes.
3. Are all of the items being installed truly necessary for the tools to run? If so, would you be open to discussing this, as well as points 1 & 2 for potential improvements (and a possible contribution of a runner to the project)?

Well, this is very interesting, and I have been working with something similar using a mirror on GitHub. Please have a look at the following comments, as I'm interested in moving everything here (if that would be possible). 1. Where is the runner hosted? I know I have something I can contribute as a Forgejo runner, but judging from the code, I assume this runs on GitHub infrastructure. This comes with a variety of concerns, but the most important one is availability for open-source projects. Yes, scale is of no concern at the moment, but even a playground can get... well... busy, especially during trial-and-error development, which means that with a little effort, the setup will hit its limits and stop working. 2. How was this code generated? There are a lot of repeated steps that should be abstracted somehow to separate the logic between "CI" and "code being run" (especially those EOF lines are completely redundant, and can be handled in 3 different ways). In general, I feel it is quite cleaner to have the YAML be a caller for other items, instead of dumping code inside the `.yml` file, for maintainability purposes. 3. Are all of the items being installed truly necessary for the tools to run? If so, would you be open to discussing this, as well as points 1 & 2 for potential improvements (and a possible contribution of a runner to the project)?

zenobit commented 2025年11月29日 19:21:20 +01:00

1. Where is the runner hosted? I know I have something I can contribute as a Forgejo runner, but judging from the code, I assume this runs on GitHub infrastructure. This comes with a variety of concerns, but the most important one is availability for open-source projects. Yes, scale is of no concern at the moment, but even a playground can get... well... busy, especially during trial-and-error development, which means that with a little effort, the setup will hit its limits and stop working.

Runner is codeberg-medium so hosted on Codeberg itself
From GitHub is pulled Void OCI image, because that is official source of Void OCI images

2. How was this code generated? There are a lot of repeated steps that should be abstracted somehow to separate the logic between "CI" and "code being run" (especially those EOF lines are completely redundant, and can be handled in 3 different ways). In general, I feel it is quite cleaner to have the YAML be a caller for other items, instead of dumping code inside the .yml file, for maintainability purposes.

Sure runned code could be separated to scripts called from yaml itself, but I like to have everything in one file. To not have to edit multiple files while I am trying to get it work. Redundant because I splited to more steps from one.

3. Are all of the items being installed truly necessary for the tools to run? If so, would you be open to discussing this, as well as points 1 & 2 for potential improvements (and a possible contribution of a runner to the project)?

Not everything installed is really necessary. Something was left there after my changes I suppose. As I stated this is my first try to use CI on Codeberg. I am already made a lot of CIs on github (not for xut), but testing if Codeberg CI is reliable enough to finaly switch to Codeberg as my main dev platform

I love to discuss, improve and include contributions from anyone interested...

> 1. Where is the runner hosted? I know I have something I can contribute as a Forgejo runner, but judging from the code, I assume this runs on GitHub infrastructure. This comes with a variety of concerns, but the most important one is availability for open-source projects. Yes, scale is of no concern at the moment, but even a playground can get... well... busy, especially during trial-and-error development, which means that with a little effort, the setup will hit its limits and stop working. Runner is `codeberg-medium` so hosted on Codeberg itself From GitHub is pulled Void OCI image, because that is official source of Void OCI images > 2. How was this code generated? There are a lot of repeated steps that should be abstracted somehow to separate the logic between "CI" and "code being run" (especially those EOF lines are completely redundant, and can be handled in 3 different ways). In general, I feel it is quite cleaner to have the YAML be a caller for other items, instead of dumping code inside the `.yml` file, for maintainability purposes. Sure runned code could be separated to scripts called from yaml itself, but I like to have everything in one file. To not have to edit multiple files while I am trying to get it work. Redundant because I splited to more steps from one. > 3. Are all of the items being installed truly necessary for the tools to run? If so, would you be open to discussing this, as well as points 1 & 2 for potential improvements (and a possible contribution of a runner to the project)? Not everything installed is really necessary. Something was left there after my changes I suppose. As I stated this is my first try to use CI on Codeberg. I am already made a lot of CIs on github (not for xut), but testing if Codeberg CI is reliable enough to finaly switch to Codeberg as my main dev platform I love to discuss, improve and include contributions from anyone interested...

zenobit commented 2025年11月29日 20:02:17 +01:00

Check run on PR
To see how looks like

Check [run](https://codeberg.org/oSoWoSo/xut/actions/runs/64/jobs/0/attempt/1) on PR To see how looks like

AngMits commented 2025年11月30日 15:01:16 +01:00

@zenobit wrote in #53 (comment):

Check run on PR To see how looks like

Alright, this is familiar. I've used GitHub Actions before myself, and from the documentation, it looks like Forgejo is following the same logic.

Since the runner is already hosted here (on Codeberg), the main parts of the PR should be merged, including the required changes on the repository (enabling actions, etc.).

@mobinmob should be the one to do this, as the owner. 👆

As for the actions themselves, I'll take another look. I believe all .xut calls can be moved to a shellspec test (or multiple ones). I can prepare a PR with the necessary actions (pulling shellspec, and the test file/suite/whatever you may want to call this for now). If I'm not mistaken, they are used to test the tool, which is a little too verbose for my taste. Something like shellspec can be "tuned" to provide more meaningful results (as is its design).

Some reordering might be necessary (installing tools, creating users, etc.), but that's an improvement consideration.

For now, I'd say that activating actions to run on this repo is the first step, with the other improvements following.

I don't know how much time I can contribute, but I'll try to provide something concrete as soon as possible. As I said before, I've been toying with this idea for a while, and your PR is already halfway there (or more like 90% there). I'll run the code on my fork, just to verify my ideas. Thanks for the incentive to push this forward and all the associated work to get it running!

@zenobit wrote in https://codeberg.org/mobinmob/xut/pulls/53#issuecomment-8594970: > Check [run](https://codeberg.org/oSoWoSo/xut/actions/runs/64/jobs/0/attempt/1) on PR To see how looks like Alright, this is familiar. I've used GitHub Actions before myself, and from the documentation, it looks like Forgejo is following the same logic. Since the runner is already hosted here (on Codeberg), the main parts of the PR should be merged, including the required changes on the repository (enabling actions, etc.). @mobinmob should be the one to do this, as the owner. :point_up_2: As for the actions themselves, I'll take another look. I believe all `.xut` calls can be moved to a shellspec test (or multiple ones). I can prepare a PR with the necessary actions (pulling shellspec, and the test file/suite/whatever you may want to call this for now). If I'm not mistaken, they are used to test the tool, which is a little too verbose for my taste. Something like shellspec can be "tuned" to provide more meaningful results (as is its design). Some reordering might be necessary (installing tools, creating users, etc.), but that's an improvement consideration. For now, I'd say that activating actions to run on this repo is the first step, with the other improvements following. I don't know how much time I can contribute, but I'll try to provide something concrete as soon as possible. As I said before, I've been toying with this idea for a while, and your PR is already halfway there (or more like 90% there). I'll run the code on my fork, just to verify my ideas. Thanks for the incentive to push this forward and all the associated work to get it running!

zenobit commented 2025年11月30日 23:07:03 +01:00

PS: Not familiar with shellspec (yet)
I thought about using clitest
portable POSIX shell script that performs automatic testing in Unix command lines

PS: Not familiar with shellspec (yet) I thought about using [clitest](https://github.com/aureliojargas/clitest) portable POSIX shell script that performs automatic testing in Unix command lines

mobinmob commented 2025年12月01日 07:13:54 +01:00

Thank you both for this :)
Automated testing/linting/formating is the only way to keep everyone (moderately) sane as xut grows :)
I am on a cleanup/optimising mode before a release. 0.4.1 will be much better, in (a large) part due to the work @zenobit has done.

Thank you both for this :) Automated testing/linting/formating **is the only way** to keep everyone (moderately) sane as xut grows :) I am on a cleanup/optimising mode before a release. 0.4.1 will be much better, in (a large) part due to the work @zenobit has done.

AngMits commented 2025年12月01日 11:23:56 +01:00

@zenobit please have a look at my fork. There's working code (at least for the running part).

That's as far as I could go within a short amount of time. There are also working tests with shellspec with all the required actions (feel free to peruse the runs for results).

Let me know what you think! I removed some steps to validate the idea, and used a slightly smaller instance (maybe bump to the previous larger if required).

@zenobit please have a look at my fork. There's working code (at least for the running part). That's as far as I could go within a short amount of time. There are also working tests with shellspec with all the required actions (feel free to peruse the runs for results). Let me know what you think! I removed some steps to validate the idea, and used a slightly smaller instance (maybe bump to the previous larger if required).

AngMits commented 2025年12月01日 22:51:49 +01:00

I did a bit more work (with patchsets to avoid clutter). You can find a run here:
https://codeberg.org/AngMits/xut/actions/runs/21/jobs/0/attempt/1

I should fix signing and other typical stuff, but it's a properly working solution, with a plain test framework.
Feel free to grab the code (if you prefer it), and incorporate it into this PR for clarity's sake, and keeping things leaner in this upstream.

I did a bit more work (with patchsets to avoid clutter). You can find a run here: https://codeberg.org/AngMits/xut/actions/runs/21/jobs/0/attempt/1 I should fix signing and other typical stuff, but it's a properly working solution, with a plain test framework. Feel free to grab the code (if you prefer it), and incorporate it into this PR for clarity's sake, and keeping things leaner in this upstream.

zenobit commented 2025年12月01日 22:57:54 +01:00

I like colors
But why is still falling?

PS: I will play a bit with your shellspec code
💌

I like colors But why is still falling? PS: I will play a bit with your shellspec code 💌

zenobit commented 2025年12月02日 00:23:41 +01:00

Looks like you are also trying woodpecker
What are advantages against plain forgejo actions?

Looks like you are also trying **woodpecker** What are advantages against plain forgejo actions?

AngMits commented 2025年12月02日 16:43:58 +01:00

@zenobit wrote in #53 (comment):

Looks like you are also trying woodpecker What are advantages against plain forgejo actions?

Woodpecker is an open-source fork of Drone (that's the short version), and it is a container-based CI system. This was at some point considered for Codeberg, but the decision came down to use the Forgejo system.

I'm using Woodpecker as I have it already set up as a GitHub app on minimal infrastructure.
Pros:

1. I can administer it at will (versions/underlying hardware/etc.)
2. It is already connected as an app to my GitHub account, and I can validate ideas there
3. I'm using it for other pipelines

Cons:

1. So far, it requires some infrastructure that needs maintenance (I'm glad to do it, but it's not optimal for larger projects)
2. It does not "natively" connect to Codeberg, which doesn't help the project.

For this project, there is zero benefit. I committed the code to keep everything concise.

@zenobit wrote in https://codeberg.org/mobinmob/xut/pulls/53#issuecomment-8637702: > Looks like you are also trying **woodpecker** What are advantages against plain forgejo actions? Woodpecker is an open-source fork of Drone (that's the short version), and it is a container-based CI system. This was at some point considered for Codeberg, but the decision came down to use the Forgejo system. I'm using Woodpecker as I have it already set up as a GitHub app on minimal infrastructure. Pros: 1. I can administer it at will (versions/underlying hardware/etc.) 2. It is already connected as an app to my GitHub account, and I can validate ideas there 3. I'm using it for other pipelines Cons: 1. So far, it requires some infrastructure that needs maintenance (I'm glad to do it, but it's not optimal for larger projects) 2. It does not "natively" connect to Codeberg, which doesn't help the project. For this project, there is zero benefit. I committed the code to keep everything concise.

AngMits commented 2025年12月02日 16:56:02 +01:00

@zenobit wrote in #53 (comment):

I like colors But why is still falling?

PS: I will play a bit with your shellspec code 💌

It's failing because the tests are probably wrong (or they have the wrong setup). 😆This was a very simplistic attempt to use a test framework with a focus on POSIX-compatible shells, with whatever input/output I could use (with the help of @mobinmob, who provided guidance in invoking xut). I have experience in higher-level test frameworks.

Feel free to explore it. Its syntax is clear, and it is quite flexible. I believe that all the calls you have put as steps there (building various packages) can be placed under "tests", with slightly better naming, handling exit codes, output to stdout, etc, and avoiding the raw output (which isn't as helpful as assertions on specific items).

And, yes, colors are the way to go! 🎉 Joking aside, they do help in quickly identifying tests (pass/fail/warn/skip, or whatever the frameworks provide), similarly to syntax highlighting. Functionally inert, but mentally helpful.

@zenobit wrote in https://codeberg.org/mobinmob/xut/pulls/53#issuecomment-8636715: > I like colors But why is still falling? > > PS: I will play a bit with your shellspec code :love_letter: It's failing because the tests are probably wrong (or they have the wrong setup). 😆This was a very simplistic attempt to use a test framework with a focus on POSIX-compatible shells, with whatever input/output I could use (with the help of @mobinmob, who provided guidance in invoking `xut`). I have experience in higher-level test frameworks. Feel free to explore it. Its syntax is clear, and it is quite flexible. I believe that all the calls you have put as steps there (building various packages) can be placed under "tests", with slightly better naming, handling exit codes, output to stdout, etc, and avoiding the raw output (which isn't as helpful as assertions on specific items). And, yes, colors are the way to go! 🎉 Joking aside, they do help in quickly identifying tests (pass/fail/warn/skip, or whatever the frameworks provide), similarly to syntax highlighting. Functionally inert, but mentally helpful.

zenobit commented 2025年12月23日 01:07:17 +01:00

I think is ready for merge @AngMits @mobinmob

Is using clitest instead of shellspec
clitest seems to me much easier to understand and can run test from text/md files

I added tests to xut README.md to show how it works (as example)

Could be changed to your liking @mobinmob

Cherry pick desired changes or tell me what i should change/remove

🚀

• CI to test xut
• xut-tests.md
• README.md from clitest in tests folder
• Added some tests into xut README.md
• FORCE_COLOR not yet work for me... Added as test to force xut show colors in CI
• Added .editorconfig
• bit improved formatting in xut (Hope I didn't brake anything this time 😱)

PS: To see actions run take a look in my actions

HOWGH

I think is ready for merge @AngMits @mobinmob Is using clitest instead of shellspec clitest seems to me much easier to understand and can run test from text/md files I added tests to xut README.md to show how it works (as example) Could be changed to your liking @mobinmob Cherry pick desired changes or tell me what i should change/remove 🚀 - CI to test xut - xut-tests.md - README.md from clitest in tests folder - Added some tests into xut README.md - FORCE_COLOR not yet work for me... Added as test to force xut show colors in CI - Added .editorconfig - bit improved formatting in xut (Hope I didn't brake anything this time 😱) PS: To see actions run take a look in my [actions](https://codeberg.org/oSoWoSo/xut/actions) HOWGH

mobinmob commented 2026年01月02日 13:51:19 +01:00

@zenobit

Thanks A LOT for doing this. I like a lot of it.
I would like to have all tests outside the file - It is really nice that both shellspec and clitest supports that and you implement that for clitest.
I also like the simplified approach @AngMits has taken with the yaml and shellspec.
That is not a purely aesthetic configuration. I want a) the yaml file to be more laconicand declarative (less like a script) and also b) to be able to run the tests easily without the ci using the makefile.
I will probable merge the two approaches and have tests using both tools.
Probably there should be a way to either carry the shellspec and clitest in the repo or use submodules to avoid fetching them in every run.
The goal is to have v. 0.4.3 with ci :)

@zenobit Thanks A LOT for doing this. I like a lot of it. I would like to have **all** tests outside the file - It is really nice that both shellspec and clitest supports that and you implement that for clitest. I also like the simplified approach @AngMits has taken with the yaml and shellspec. That is **not** a purely aesthetic configuration. I want **a)** the yaml file to be more laconicand declarative (less like a script) and also **b)** to be able to run the tests easily without the ci using the makefile. I will probable merge the two approaches and have tests using **both** tools. Probably there should be a way to either carry the shellspec and clitest in the repo or use submodules to avoid fetching them in every run. The goal is to have v. 0.4.3 with ci :)

This pull request has changes conflicting with the target branch.