[BEAM-11569] Fixing cancel workflows

[pabloem]

Please add a meaningful description for your change here

---

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

• Choose reviewer(s) and mention them in a comment (R: @username).
• Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
• Update CHANGES.md with noteworthy changes.
• If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

Post-Commit Tests Status (on master branch)

Lang	SDK	Dataflow	Flink	Samza	Spark	Twister2
Go		---		---		---
Java
Python				---		---
XLang				---		---

Pre-Commit Tests Status (on master branch)

---	Java	Python	Go	Website	Whitespace	Typescript
Non-portable
Portable	---		---	---	---	---

See .test-infra/jenkins/README for trigger phrase, status and link of all Jenkins jobs.

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

[pabloem]

r: @aaltay
cc: @potiuk

[aaltay]

Does airflow know that we are depending on this as an artifact of their repo and will complain if they brake it :)

Joke aside, should we move to beam repo?

Approving to unblock things for now.

[pabloem]

this repository is maintained by @potiuk - furthermore, we're pinning against a specific commit, so new changes will not affect us.

I think I am okay proceeding either way.

[potiuk]

It is copied by me, indeed, but early warning - I will likely remove it soon (and recommend any project using it to switch to a new way of dealing with the problem we discussed yesterday).

I highly recommend switching to submodule approach discussed in https://lists.apache.org/thread.html/rcf7f560dad70ed02d77ad131a670e24eb815e41f92a442a3153da98b%40%3Cbuilds.apache.org%3E

The PR with working POC here: apache/airflow#13514

And just to comment on properties of this approach:

This seems to works perfectly:

1. It always links to particular SHA commit not branch
2. No code duplication
3. GitHub Review nicely incorporates the change code from submodules
   whenever submodule is updated, so it fits naturally in the review workflow.
4. Seems that we can easily make it works with Github Actions (the
   submodule needs to be checked out in previous step of the job).
5. It's even easier to pull new versions.
6. It is equally easy to add any external action at any time
7. Passes all the INFRA requirements re: review + SHA - without any checks

Literally what we are trading of in the code is this:

.gitmodules

[submodule ".github/actions/get-workflow-origin"]
path = .github/actions/get-workflow-origin
url = https://github.com/potiuk/get-workflow-origin

In your YAML:

      - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
        uses: actions/checkout@v2
        with:
          persist-credentials: false
          submodules: recursive
      - name: "Get information about the PR"
        uses: ./.github/actions/get-workflow-origin
        id: source-run-info
        with:
          token: ${{ secrets.GITHUB_TOKEN }}

Where originally you'd have:

      - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
        uses: actions/checkout@v2
        with:
          persist-credentials: false
      - name: "Get information about the PR"
        uses:
potiuk/get-workflow-origin@588cc14f9f1cdf1b8be3db816855e96422204fec  # v1_3
        id: source-run-info
        with:
          token: ${{ secrets.GITHUB_TOKEN }}

The nice thing is that it fits very nicely into GitHub Review - GitHub understands submodules and the files brought in and changes are literally part of the reviewed files (even i they are physically not in the repo). It also automatically links to the SHA commit (SHA commit is always stored in the git tree when you run git submodule add or git submodule update. Also it does not change any workflow for your contributors. They do not have to know or use submodule, it is only needed by the CI and when you want to bring new version of an action.

It seems this is a perfect solution and it is much more secure than directly linking to an external action - precisely because it nicely integrates in GitHub Review process when any changes are brought in.

[aaltay]

@potiuk - This is great and it makes a lot of sense. @pabloem - would you be willing to switch beam to this git submodule based approach as well? I do not think this is urgent as the current approach of linking to commit will work until we want the next version of this action.

/cc @tysonjh

[pabloem]

yes, #13736 changes Beam to use that approach