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".
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 "workflow
per action" however can have the benefit that you can clearly see in the
Gitihub Action output the logs separated per workflow - which makes it
easier to debug and reason about.
However similar results could be achieved by using log grouping
https://docs.github.com/en/actions/reference/workflow-commands-for-github-actions#grouping-log-lines
which I did not realize back then. So if someone would like to make PR and
add such feature - I am happy to review and merge it! You could also
potentially query for all the workflows using the API, but this is rather
dangerous IMHO - for example in Pulsar I had to exclude one of the
workflows, because it was only triggered by creating/updating an issue and
my action failed when trying to query it. Probably this could be detected
and fixed, but there are many types of workflows in Github Actions, so
spelling them out explicitly is better Idea IMHO.
Regarding "queuing the cancelling workflow. Indeed, cancel workflows will
be themselves queued - this is why "alllDuplicates" cancel mode was
introduced - I explained exactly how it works and how the "high strain"
situation is handled in this comment:
https://github.com/apache/pulsar/pull/9503#issuecomment-774644408 - I am
moving part of the explanation to the documentation of the action soon.
J.
On Tue, Feb 9, 2021 at 11:43 AM Antoine Pitrou <anto...@python.org> wrote:
>
> Hi Jarek,
>
> Le 09/02/2021 à 09:21, Jarek Potiuk a écrit :
> > And we all together try to help each other (for
> > example I helped yesterday the Pulsar team to implement most aggressive
> way
> > of cancelling their workflows https://github.com/apache/pulsar/pull/9503
> > (you can find pretty good explanation why and how it was implemented this
> > way),
>
> Thanks for doing this. I'm trying to experiment with your action and
> there's something a bit confusing in the documentation. It says for the
> "allDuplicates" action:
>
> """Cancels duplicate runs from all running workflows."""
>
> However, it doesn't seem to cancel duplicates from all running
> workflows, only from the triggering workflow. Is that true?
>
> Would there be a way to really cancel duplicates accross all workflows,
> not only the triggering workflow, without listing all the workflow files
> explicitly like you did for Pulsar?
>
>
> Ah, another concern: since the cancelling workflow is itself a workflow,
> it may be subject to the same queueing as other workflows... meaning, if
> the build queue is clogged, it will run too late to have the maximum
> effect?
>
> Thank you
>
> Regards
>
> Antoine.
>
--
+48 660 796 129
