Ruff and Black as GitHub workflow.

[Andrei-Aksionov]

Hi there 👋

As discussed in #758.

The objective is to create a github workflow to apply Ruff and Black fixes automatically on each PR and, what's more importantly, without having any config in the root folder (no .pre-commit-config.yaml or pyproject.toml).

As a baseline I used this workflow from the PyTorch-Lightning repo.
With a major change: this PR doesn't use pre-commit whatsoever.

---

The workflow is such:

1. During Auto Code-Style Fix workflow Ruff and Black are executed.
2. If any changes are made a new commit is created and pushed.
3. Other workflows either restart and run on the latest commit (after linting) or continue to work in parallel.

---

Now, step number 3. Why it has two possible outcomes?
That's because of the github_token, that is created automatically per each workflow.
And, according to the docs:

When you use GITHUB_TOKEN in your actions, all of the interactions with the repository are on behalf of the Github-actions bot. The operations act by Github-actions bot cannot trigger a new workflow run.

which means that despite the change in the PR (if Ruff and Black changed files) and cancel-in-progress option specified in cpu-tests.yaml, all the remaining workflows will not restart and just continue to work in parallel.

In order to avoid it, we have to use PAT (Personal Access Token) in the workflow.

1. Create a PAT for the repo with “Contents: read and write” permission.
2. Add this PAT to the secrets section of the repo's setting with the name action-secret.
3. Add read-write permissions for the bot (repo Settings -> Actions -> General -> Workflow Permissions -> Read and Write permissions).

After that, rerun failed jobs and everything should work. In theory 😊.

[carmocca]

@Borda Do you have any advice about how to resolve the permissions to do this?

[carmocca]

I don't think this works if the PR comes from a fork

[Borda]

Only use pull_request_target but that won't likely push to forked PRs, so the best way would be to install precommit bot if you really want also fixing... Otherwise our utilities repo has precommit workflow for reuse

[Andrei-Aksionov]

@carmocca From the logs I see that the issue is with the token (it wasn't found):

Missing input "github_token: ${{ secrets.GITHUB_TOKEN }}".

When I did it in my fork of the repo, I did these steps (maybe you've missed one):

1. Created a PAT from my account's settings: created PAT with name Lit-GPT-token and Content permissions. Copied generated token.
2. In repo's settings (Settings -> Secrets and variables -> Actions -> New repository secret) I created a new secret with a name action-secret and in the field secret I pasted PAT generated token (not name!)
3. Used that secret in the workflow

So maybe you've used a PAT with name PAT_GHOST, when you actually should have used a secret.

---

@Borda
I did all experiments on my fork of Lit-GPT and it worked fine. Or maybe you've meant something else?
Plus I don't see how pre-commit would work differently here, as the issue is in the way we push changes back.
The goal is to not have a config file in the root of the repo. And pre-commit requires .pre-commit-config.yaml.

---

One more thing @carmocca
github_token field should contain secret token first and then github.token. Otherwise, indeed, in a fork repo it will not work as, most likely, forks will not have this secret tied to PAT. In case when two tokens are provided the second one is a fallback option. So in a repo where there is no such a secret a standard token will be used. The only negative is that after a commit is pushed by a linter workflow, the other workflows won't be stopped. But it's a minor issue I would say.

[Borda]

When I did it in my fork of the repo, I did these steps (maybe you've missed one)

That is correct, GH doesn't not share secrets fork PRs by design

[Borda]

Plus I don't see how pre-commit would work differently here, as the issue is in the way we push changes back.

Bot is third party actor, so it behave identical for main repo development as well as forked contributing

[carmocca]

I believe Jirka is right here and any action-based solution is doomed since PATs cannot be shared with forks with pull_request events.

[Andrei-Aksionov]

I never expected that a PAT (or more specifically a secret tied to the PAT) is shared with forks. I guess that's why they are called a secret and a personal token.
That's why I provide in the workflow two tokens to choose from: the secret and the default github token.

github_token: ${{ secrets.action_secret || github.token }}

so if there is no secret with name action_secret then the github.token is used.

The only difference in the workflow will be that with the secret all the running workflows will be restarted if there are any changes were made after linting. With the default token they will be running in parallel (on outdated commit).

[Andrei-Aksionov]

@Borda You are talking about this pre-commit bot: https://pre-commit.ci/ ?

configuration: zero configuration setup -- nothing is needed beyond the .pre-commit-config.yaml file you already have!

And for this repo this config file is no bueno.

[carmocca]

Since this is in a deadlock I'll go ahead and close it. We can revisit if one of the requirements is relaxed in the future.

Thanks for trying though!