enable `forgejo-runner validate` to run on files in repository without cloning it

Freso commented

2025-09-16 15:37:11 +00:00

How to use this feature request

Please describe your first hand experience in a comment to show why you are interested into the same feature.
Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
Subscribe to receive notifications on status change and new comments.

First hand experience

I’m trying to add a pre-commit hook for forgejo-runner.
During testing (and implementing automated testing), I’ve realised that there isn’t a good way to validate files in a repository that haven’t yet been committed.
forgejo-runner validate --repository makes a clone of the repository and validates that, which obviously doesn’t include not-yet-committed files or changes to files
forgejo-runner validate --path
1. only takes one file at a time
2. requires you to know in advance whether this file is an action or a workflow file

Needs and benefits

Not being able to test the uncommitted status of a repository without specifying individual files by hand makes it hard to implement a pre-commit hook (or even manually make a git or other VCS pre-commit hook) since we’d want to test it before it enters the repository, not after.

Feature Description

A flag (--local?) to validate ^(\.(forgejo|github|gitea)/workflows/[^/]+|action)\.ya?ml$ files in the current directory, regardless of whether they’ve been committed or not, and without having to specify each file.

Alternatively(/additionally?), let --path take multiple arguments and let it decide whether to validate as action or workflow files based on their paths/filenames (if --action or --workflow is not explicitly given).

What needs to happen before a feature request is ready to be implemented?

Users can complete the first step (accumulating first and experience) on their own, even if this feature request did not catch the eye of someone with the necessary skills to implement it. And when it reaches that point, it will stand out and have a much higher chance of being implemented.

A few other users contributed their own first hand experience.
To fully grasp the scope of a feature request, and to brainstorm possible solutions, a feature request will generally wait until several users have provided their perspective.
Thumbs-up reactions help gauge popularity, but do not provide the same amount of useful information.
The "Needs and benefit" and "Feature description" are finalized.
Results from discussions and additional user experiences are incorporated into a final summary to provide a single reference for the developers working on this change.
This can be done by the author of the issue or anyone else in a followup comment.
The label Stage/Idea is changed to Stage/Ready.
Feature request is created in the repository where the code resides.
Depending on the feature request it can be in Forgejo, Forgejo runner or Forgejo ACT.
A copy/paste of the "Needs and benefit" and "Feature description" should be used, with link to this issue so the developer knows where to find more details if they need to.

### How to use this feature request * Please describe your first hand experience in a comment to show why you are interested into the same feature. * Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue. * Subscribe to receive notifications on status change and new comments. ### First hand experience - I’m [trying to add a `pre-commit` hook for `forgejo-runner`](https://code.forgejo.org/forgejo/runner/pulls/1002). - During testing (and implementing automated testing), I’ve realised that there isn’t a good way to validate files in a repository that haven’t yet been committed. - `forgejo-runner validate --repository` makes a clone of the repository and validates that, which obviously doesn’t include not-yet-committed files or changes to files - `forgejo-runner validate --path` 1. only takes one file at a time 2. requires you to know in advance whether this file is an action or a workflow file ### Needs and benefits Not being able to test the uncommitted status of a repository without specifying individual files by hand makes it hard to implement a `pre-commit` hook (or even manually make a git or other VCS pre-commit hook) since we’d want to test it before it enters the repository, not after. ### Feature Description A flag (`--local`?) to validate `^(\.(forgejo|github|gitea)/workflows/[^/]+|action)\.ya?ml$` files in the current directory, regardless of whether they’ve been committed or not, and without having to specify each file. Alternatively(/additionally?), let `--path` take multiple arguments and let it decide whether to validate as action or workflow files based on their paths/filenames (if `--action` or `--workflow` is not explicitly given). ### What needs to happen before a feature request is ready to be implemented? Users can complete the first step (accumulating first and experience) on their own, even if this feature request did not catch the eye of someone with the necessary skills to implement it. And when it reaches that point, it will stand out and have a much higher chance of being implemented. 1. **A few other users contributed their own first hand experience.** To fully grasp the scope of a feature request, and to brainstorm possible solutions, a feature request will generally wait until several users have provided their perspective. Thumbs-up reactions help gauge popularity, but do not provide the same amount of useful information. 1. **The "Needs and benefit" and "Feature description" are finalized.** Results from discussions and additional user experiences are incorporated into a final summary to provide a single reference for the developers working on this change. This can be done by the author of the issue or anyone else in a followup comment. 1. **The label `Stage/Idea` is changed to `Stage/Ready`.** 1. **Feature request is created in the repository where the code resides.** Depending on the feature request it can be in [Forgejo](https://codeberg.org/forgejo/forgejo/issues/new?template=.forgejo%2fissue_template%2ffeature-request.yaml), [Forgejo runner](https://code.forgejo.org/forgejo/runner/issues/new?template=.forgejo%2fissue_template%2ffeature-request.yaml) or [Forgejo ACT](https://code.forgejo.org/forgejo/act/issues/new). A copy/paste of the "Needs and benefit" and "Feature description" should be used, with link to this issue so the developer knows where to find more details if they need to.

Freso added the

Stage

Idea

label

2025-09-16 15:37:11 +00:00

Freso referenced this issue from forgejo/runner

2025-09-16 15:39:39 +00:00

feat: add pre-commit hook for validator #1002

earl-warren commented

2025-09-16 16:32:22 +00:00

This is a compelling use case.

earl-warren commented

2025-09-16 16:38:56 +00:00

I think the --clonedir option does what you need.

$ forgejo-runner-11.0.0 validate --clonedir . --repository .
.forgejo/workflows/build.yml workflow schema validation OK
.forgejo/workflows/sync.yml workflow schema validation OK
.forgejo/workflows/test.yml workflow schema validation OK

I think the `--clonedir` option does what you need. ```sh $ forgejo-runner-11.0.0 validate --clonedir . --repository . .forgejo/workflows/build.yml workflow schema validation OK .forgejo/workflows/sync.yml workflow schema validation OK .forgejo/workflows/test.yml workflow schema validation OK ```

Freso commented

2025-09-16 17:12:17 +00:00

Author

That does indeed seem to work! But it feels quite hacky. 😆

But at least it unblocks forgejo/runner#1002 and lets me return to that. 🫡

That does indeed seem to work! But it feels quite hacky. 😆 But at least it unblocks https://code.forgejo.org/forgejo/runner/pulls/1002 and lets me return to that. 🫡

earl-warren commented

2025-09-16 19:37:32 +00:00

That does indeed seem to work! But it feels quite hacky. 😆

Agreed. When diving in the implementation it is actually straightforward but it feels hacky from the CLI. The solution would be to never clone when it is a directory. But then it would require writing tests using URLs for the sake of getting coverage and this is a little more work.

> That does indeed seem to work! But it feels quite hacky. 😆 Agreed. When diving in the implementation it is actually straightforward but it feels hacky from the CLI. The solution would be to never clone when it is a directory. But then it would require writing tests using URLs for the sake of getting coverage and this is a little more work.

earl-warren commented

2025-09-16 19:38:43 +00:00

Feel free to convert this feature request into doing that. Or close it. It is a border case that probably does not deserve the effort. But it may just me being lazy.

earl-warren referenced this issue from a commit

2025-09-17 11:00:19 +00:00

feat: validate --directory alternative to --repository to not clone

~~earl-warren referenced this issue from forgejo/runner 2025-09-17 11:03:51 +00:00~~

feat: validate --directory alternative to --repository to not clone #1008