InnerSourceCommons / InnerSourcePatterns

Proven approaches that can guide you through applying open source best practices within your organization
https://patterns.innersourcecommons.org
Creative Commons Attribution Share Alike 4.0 International
744 stars 181 forks source link

Markdownlint Action is running twice #267

Open spier opened 3 years ago

spier commented 3 years ago

I noticed that the markdownlint GitHub Action that we have is running twice on the same PR. It is mostly a cosmetic problem and it also might be a bit confusing for people.

I know that we could prevent it by limiting the action workflow execution to pushes to master like in this GHA configuration. However that seems to have other undesirable consequences.

I wonder if there is some way to do this?

Example:

See the bottom of https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/261/

Screenshot:

markdownlint-running-twice

spier commented 3 years ago

hi @nschonni. I filed this issue to keep track of the duplicate Action execution that I am seeing.

I remember that we had already discussed this elsewhere but I couldn't find that conversation thread anymore. I think your argument for not limiting the execution to master only was something related to enabling contributors to fix issues on a branch, without even having to open a PR, right?

nschonni commented 3 years ago

Yeah, you can look at something like https://github.com/fkirc/skip-duplicate-actions#skip-concurrent-workflow-runs to trim the extra runs

spier commented 3 years ago

Hmm, I see. Feels a little bit strange to add yet one more Action to skip the extra runs of this Action.

That's why I was wondering if this is a shortcoming in GitHub Actions itself, or if we are just using it the wrong way.

It would help me if you could elaborate on the experience from a contributor perspective that you are after. I found the previous comment again where you had mentioned this:

nschonni If you limit this to only pushes to the default branch, you won't get checks on PR branches ahead of time, which leads to churn after opening a PR. The filter can also be useful for jobs that really depend on paths in a particular branch.

Thanks for your help in understanding this, so that we can then explore wat options we have to solve this.