added check for crlf to workers.txt

[StrangeDrVN]

• worker.txt needs to be in CRLF
• add scripts/commands/workers/validate.ts and integrate it to check.yml

[freearhey]

Maybe it would be better to create a script commands/workers/validate.ts similar to channels/validate.ts and call it from the action.

[StrangeDrVN]

Maybe it would be better to create a script commands/workers/validate.ts similar to channels/validate.ts and call it from the action.

That makes sense. By 'call it from the action.' you mean to the check.yml?

[freearhey]

I think so.

[StrangeDrVN]

@freearhey Isn't this because the script has not been added yet? And the script addition doesn't seem to be identified by the check.yml.

##[group]Run npm run workers:validate
npm run workers:validate
shell: /usr/bin/bash -e {0}
##[endgroup]

> workers:validate
> tsx scripts/commands/workers/validate.ts

sh: 1: tsx: not found
##[error]Process completed with exit code 127.

[freearhey]

Yes, according to the report https://github.com/iptv-org/epg/actions/runs/29319998749/job/87042801320?pr=3207 this is the reason.

[tohenk]

Why don't we use simple solution using .gitattributes to address different EOL across OSes?

[freearhey]

We tried it, but if a file with an incorrect line ending made its way into the repository, it would block all further commits: #2871

[freearhey]

Could you also add a test for workers/validate.ts?

[tohenk]

@freearhey Can I have write access to this repository?

[freearhey]

@tohenk But you already have write access to all repositories in the iptv-org:

[freearhey]

If the new .gitattributes will work as intended (#3229), do we even need a separate script to check a single .txt file?

[StrangeDrVN]

If the new .gitattributes will work as intended (#3229), do we even need a separate script to check a single .txt file?

Does adding new server/link via GitHub web editor to the .txt ignore .gitattributes and save with LF?

Wouldn't it be better to add an issue form to add a server instead of creating a PR?

[freearhey]

Does adding new server/link via GitHub web editor to the .txt ignore .gitattributes and save with LF?

Good question.

Wouldn't it be better to add an issue form to add a server instead of creating a PR?

Well, I think creating a separate template and script just to add a single line to a file is definitely overkill.

Resolved.

[fridrich]

If the new .gitattributes will work as intended (#3229), do we even need a separate script to check a single .txt file?

Not only that it does not work, but introducing the * text=auto simply introduced a system dependency. It makes all the files be reformated on linux on any git invocation. I had to remove the .gitattributes file in my local checkout, because even git reset --hard was leaving modified files. It is quite difficult to get the .gitattributes right, and a pre-commit hook is the best thing to do.

[freearhey]

I had to remove the .gitattributes file in my local checkout, because even git reset --hard was leaving modified files

Here's another trick that might help:

In the .git/info folder, create a file named attributes and add * -text to it. This overrides any rules specified in .gitattributes and it will not be reflected in the commit history.

[fridrich]

In the .git/info folder, create a file named attributes and add * -text to it. This overrides any rules specified in .gitattributes and it will not be reflected in the commit history.

That is a very useful hint and I will for sure use it. There is still my point that this your approach is way better then the .gitattributes, since they are very difficult to get right unless one understands the thing inside out. Currently, on a linux system a clean git clone results in a dirty repository.

[tohenk]

We need renormalize after adding .gitattributes in a new PR.

git add --renormalize .

[fridrich]

We need renormalize after adding .gitattributes in a new PR.

git add --renormalize .

Still that * text=auto will do what? Will the next entries override it or will they catch only what was not caught before.

[freearhey]

We need renormalize after adding .gitattributes in a new PR.

Has anyone done this kind of PR yet? And in the end, do we still need workers:validate?

[tohenk]

Has anyone done this kind of PR yet? And in the end, do we still need workers:validate?

It won't be needed anymore.