If you view the discussion for the resolve link, I have detailed alternative solutions to trigger the lint workflow correctly, but I can't say that they're any better. If adopting the referenced create-pull-request action, it can create temporary/short-lived branches per PR among other features. Triggering another workflow from it making a pull request is possible, but it requires one of:

• SSH deploy key
• Github App generated token
• PAT

I don't see an issue with the approach proposed here. It's the simplest "fix", and it makes it clear that the check was skipped (remember that these check status will show "success" if a workflow skips internally IIRC?) via explicit message beside the check.

If someone wants to resolve it a different way that's fine 👍 I just lack the time to put towards alternatives approaches. This should at least work in the meantime 😅

Not against it - don't get me wrong. Just my incentive to get it working like it should. I will see if i can reproduce this on my repo and if i will find a solution working without PAT,..

1. If the goal is to skip the lint-test, why not just exclude CONTRIBUTORS.md in linting.yml?
2. What are your concerns with using a PAT? It seems to be the simplest solution and security wise as secure as any other SECRET we use.

1. If the goal is to skip the lint-test, why not just exclude CONTRIBUTORS.md in linting.yml?

Because linting.yml is set in the repository settings as a mandatory check to run on every interaction. We could discuss on removing this but imho its good practice to force as many workflows as possible to run to cover all possible circumstances.

2. What are your concerns with using a PAT? It seems to be the simplest solution and security wise as secure as any other SECRET we use.

It is scoped to an individual person. Sadly there is no "organization PAT" available right now.

I understand. What is the downside of "scoped to an individual person", beside it's ugly not having a org PAT?

I understand. What is the downside of "scoped to an individual person", beside it's ugly not having a org PAT?

Mutiple issues here:

1. The PAT is only valid for a specific time period, then it needs to be replaced (this implies that the one who brought it in need s to be an active maintainer still and for the whole period)
2. The PAT can only be scoped to topics (repo/packages/profile/api/...) but not to specific instances of it. So if you provide the PAT and i somehow manage to get it (malicious attacks on workflow files) i would be able to control your personal account (at least on the topics the PAT hat - but in case of a PR it would be read and write to repos i think)
3. IIRC One needs to be org or Repo Admin (maintainer is not enough) to set those secrets on org level for example which limits the people that can actually access this setting
4. ...I'm sure i find more if i think deeper on this topic

All in all i use PATs myself in a lot of actions (mostly to trigger other workflows, so exact same issue) bc it is the easiest way to archive things. But I am a single person and not a github org which is the biggest difference in terms of security and responsibilities. Maybe it will turn out that the PAT flaws are smaller than the benefit we gain on using them and we stick with them. Experience will show.

As mentioned earlier i will try to rebuild the environment/setting in my scope and see if i find a solution that "works" but it will take some time.

As mentioned earlier i will try to rebuild the environment/setting in my scope and see if i find a solution that "works" but it will take some time.

So in the meantime, we merge this one or should we wait?

Merge it in the meantime. Lets See If it is working.
If not we need to fix it anyways otherwise i have time for improvements ;)

PAT will also make the action/workflow appear to be performed by you. Eg, we won't have a bot opening the PR, it'll be your account. With the SSH deploy keys you can make this work with the bot IIRC, and it allows better restricting the scope of permission to single repo. I can't recall how the Github App generated tokens compare, but if you follow that link I provided it covers all pro/cons well.

If you'd like an example of using SSH Key deployment, I came across this AWS project PR which implements it, could be good reference? I also advise looking into that create-pull-request action as it probably simplifies the workflow and can take care of the PR/branch management while the contributors action just does what it's good at.

This doesn't seem to work, see here

git rev-parse contributors-update does not return "a 40 character SHA1".

does not return "a 40 character SHA1".

It should...

On my system:

$ git rev-parse main
b1334033317566fd58858c1d43e60d810ed6502b

$ git log -n 1 main --pretty=format:"%H"
b1334033317566fd58858c1d43e60d810ed6502b

In the action the step gets the hash and sets it to an output variable correctly AFAIK:

id: commit-data
run: 'echo "::set-output name=head_sha::$(git rev-parse contributors-update)"'

Although the workflow report you linked shows this error output for that command:

fatal: ambiguous argument 'contributors-update': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

Is this branch not locally available at the time the command is run? I thought you had checked out the repo and created the branch with a commit pushed in the earlier steps?

I unfortunately don't have time to setup a throwaway repo to iterate on this workflow so that the required info is available. Running either of the two commands I showed above, but giving an invalid branch name results in the same error output, so I'm rather positive that's the cause of the failure.

I can create another PR to add a step that I think would resolve it:

That does a shallow checkout of the ref branch, and if path is omitted should checkout to the active location instead of a sub-directory.

The current workflow earlier steps:

Looks like it checks out master branch, then creates the contributors-update branch but presumably that's where the local change is pushed to rather than creating the same branch locally? For the fix I added, we need the relevant commit locally that matches the SHA for the PR.

I am reminded that a PR also has a "merge" commit that's separate from the PR commits which is to provide the diff from the PR and the target branch, this isn't publicly viewable as a commit IIRC, but I do recall the preview docs workflow when testing different configs could target that and add comments to it like any other commit. I'm not sure if this special type of PR commit has relevance to the check status, I don't think it does.. just mentioning it if it turns out I'm mistaken about the correct commit SHA to retrieve.

Is this branch not locally available at the time the command is run?

That was the problem 👍

I was writing a response and doing some investigation, then decided I could put out a PR again for this workflow (just not properly test it unfortunately). Looks like you bet me to it with a PR though 😅

The actions/checkout@v2 puts the working dir in a detached HEAD state. So simply git checkout to the ref/branch we want should fix the isssue