I updated the docs slightly:
* https://github.com/potiuk/cancel-workflow-runs#the-action-target-workflow
-> description about the workflow the action acts on
*
https://github.com/potiuk/cancel-workflow-runs#tackling-the-high-queue-strain-situation
-> I added "Tackling the high queue strain situation" chapter - where I
explain how `allDuplicates` mode helps to fight it.
J
On Tue, Feb 9, 2021 at 7:53 PM Jarek Potiuk <ja...@potiuk.com> wrote:
> > Er... so "source" workflow is the triggering workflow, and "target"
> workflow is the cancelling workflow? Or is it something else? I'm
> afraid all those explanations are a bit confusing to me :-)
>
> Precisely. Unfortunately GA's features for the "special" workflows are as
> powerful as they are complex, and even they did not introduce a good
> terminology. The whole `workflow_run` concept is fantastic from being
> security conscious, but it is also damn difficult to wrap your head around
> it. It took me quite some time to master it and even now I have trouble
> with explaining it, sorry.
> But yes - the terminology I introduced is: PR workflow ("source workflow")
> with READ-ONLY GITHUB_TOKEN is the one that triggers the "workflow_run"
> Cancel workflow ("target workflow") (with WRITE GITHUB_TOKEN).
>
> > I would gladly try to make a PR, but my Javascript competence is
> approximately zero, unfortunately. :-S
>
> I am not at all Javascript dev. If anything I am nowadays mostly a Python
> and Bash developer (often also a Gmail writer ;) ) , but I do have a good
> deal of C/C++/Java/Groovy/Bash and a bit of Javascript under my belt.
> Actually, the action is written in TypeScript not Javascript (Typescript is
> transpiled to javascript) and developing in Typescript if you have a good
> IDE is easy :). This might be easier than you think.
>
> J.
>
> On Tue, Feb 9, 2021 at 7:34 PM Antoine Pitrou <anto...@python.org> wrote:
>
>>
>> Le 09/02/2021 à 19:28, Jarek Potiuk a écrit :
>> > Yes. I noticed this misleading line and I will update the docs shortly.
>> It
>> > should be """"Cancels duplicate runs from all running workflow *runs of
>> the
>> > workflow the action acts on*."""
>> >
>> > The action is written in the way that it always acts on a single
>> workflow.
>> >
>> > By default this is indeed the same workflow as the one run by action.
>> But
>> > there are few ways it can be a different workflow:
>> >
>> > 1) In most cases (especially when you want to enable canceling for Pull
>> > Requests from forks), the action should be run "workflow_run" event. And
>> > this even has two workflows "the source one" (for example pull_request)
>> and
>> > "the target one" (this is the workflow that the cancel action should be
>> > part of). If you specify "${{ github.event.workflow_run.id }}" as
>> > sourceRunId - then the action will act on the "Source" workflow instead
>> of
>> > the default "target one".
>>
>> Er... so "source" workflow is the triggering workflow, and "target"
>> workflow is the cancelling workflow? Or is it something else? I'm
>> afraid all those explanations are a bit confusing to me :-)
>>
>> > 2) You can explicitly specify the "workflowFileName" as I did in Pulsar
>> -
>> > then the action will act on the specified workflow.
>> >
>> > It would be possible to add a feature to the action to run on "array of
>> > workflowFileNames" - It is possible, and not very complex, but I decided
>> > not to do it, as it is just a slight improvement over the copy&pasting
>> the
>> > action to workflow file several times (As I did in pulsar).
>>
>> The "array of workflowFileNames" would be quite welcome for us, because
>> right now the amount of copy / pasting is a bit unwiedly, and it's very
>> easy to make an error:
>> https://github.com/apache/arrow/pull/9455/files
>>
>> I would gladly try to make a PR, but my Javascript competence is
>> approximately zero, unfortunately. :-S
>>
>> Best regards
>>
>> Antoine.
>>
>
>
> --
> +48 660 796 129
>
--
+48 660 796 129
