Migrate to actionlint

[TheFox0x7]

Move from jobparser to actionlint as base for job processing

---

Both PR and description are very WIP.

For now it did three things:

1. Include jobparser code in tree so I have easier time changing it (I can't find any reason as to why it shouldn't be here anyway)
2. Swap Event detection function to be use actionlint
3. Use actionlint to check syntax in webui (still needs work as it looks bad)

[TheFox0x7]

@Zettat123 @wolfogre Seeing as you are working on actions, could you take a look at this before I mess with this further?

webui check look like this for reference:

[lunny]

Once we introduce actinlint, we need to introduce it in act_runner and drop the act's parser at the same time.

[wolfogre]

@TheFox0x7 Thank you for your attempts in this direction. However, I may not have the time to provide detailed assistance recently due to personal reasons. Here are my simple thoughts on this (please understand that I haven't investigated in depth, so it may not be accurate):

• Under the current situation, are there enough pain points that make migrating to actionlint worthwhile? This requires an issue description.
• Is migrating to actionlint feasible, and is the adaptation work acceptable? Because actionlint is designed for GitHub Actions, and the syntax of Gitea Actions has slight differences, for example, uses: https://gitea.com/a/b is not valid for GitHub Actions.
• How should the functional modules be divided? Is actionlint only responsible for the validation of YAML files, or will it also be responsible for job parsing? If it is the latter, then as Lunny said, the act_runner's job parsing work should be updated synchronously. How should this be handled? Should act_runner introduce Gitea as an external package?
• Is there a better way? For example, I guess having act introduce actionlint is the most intuitive direction, as both Gitea and act_runner will depend on act.

[TheFox0x7]

First of all, no worries. I mainly started this because I already worked on this and actions before, which made me think that taking this system was a mistake - but it's too late to reverse this and I don't want that work to go to waste. Worst case I'll close this and it might be useful to someone later.

---

Under the current situation, are there enough pain points that make migrating to actionlint worthwhile? This requires an issue description.

Yes and no. Having actionlint as at least a validation layer, would give end user better errors and safeguard jobparser from bad yamls, plus access to permissions and concurrency fields. On the other hand, I did try to fully port gitea to actionlint before and there are some things which actionlint is just bad at for this use:

1. No marshaling into a regular yaml (this is a large issue)
2. on field has to always be processed and the same with steps (this is mainly annoyance as I can't do the thing jobparser does not and copy entire node which I don't need to touch)

So I don't think dropping act parser or jobparser is doable for now.

Is migrating to actionlint feasible, and is the adaptation work acceptable? Because actionlint is designed for GitHub Actions, and the syntax of Gitea Actions has slight differences, for example, uses: https://gitea.com/a/b is not valid for GitHub Actions.

Unless we explicitly add validation runs after parsing none of the additional rules will trigger - only syntax-check. So actions rule won't flag the uses url as it won't be ran. There are no syntax differences that would make this a bad idea and introducing them would mean breaking compatibility with github.

How should the functional modules be divided? Is actionlint only responsible for the validation of YAML files, or will it also be responsible for job parsing? If it is the latter, then as Lunny said, the act_runner's job parsing work should be updated synchronously. How should this be handled? Should act_runner introduce Gitea as an external package?

act_runner as far as I saw, doesn't use jobparser module at all. I did try to make actionlint do job processing and... yeah that turned into spaghetti fast. It is doable but far from fun and there would still be expression parser required.
Act_runner doesn't need any of Gitea job code as it gets regular workflows that act can run last time I looked. If anything I really don't see why jobparser is out of main tree in the first place so even pulling it in can be an improvement.

Is there a better way? For example, I guess having act introduce actionlint is the most intuitive direction, as both Gitea and act_runner will depend on act.

act already pulls actionlint as dependency and I guess here are/were some plans to use it for validation as per comment:

// BUTx2 I leave this for when we rewrite act to use actionlint for workflow validation
// so we return proper errors before any execution or spawning containers

in pkg/runner/step_run.go. But touching act is outside of my area of expertise as I get lost in that codebase very fast and don't use it in general.