-
Notifications
You must be signed in to change notification settings - Fork 14.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ci: use git submodules for (securely) using third party Github Actions #12709
ci: use git submodules for (securely) using third party Github Actions #12709
Conversation
…ions List of repositories added as submodules: EndBug/latest-tag@latest morrisoncole/pr-lint-action@v1.4.1 trilom/file-changes-action@v1.2.4 styfle/cancel-workflow-action@0.6.0 apache-superset/cached-dependencies@b90713b unsplash/comment-on-pr@v1.2.0
I need to add proper |
Codecov Report
@@ Coverage Diff @@
## master #12709 +/- ##
==========================================
+ Coverage 66.89% 66.90% +0.01%
==========================================
Files 1020 1020
Lines 49905 49905
Branches 4888 4888
==========================================
+ Hits 33384 33390 +6
+ Misses 16396 16390 -6
Partials 125 125
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! This is the recommended way which I think all Apache Projects should adopt. It has only benefits and no drawbacks:
- inner working of submodules is such actions are automatically linked via their long hash commit -- recommended security practice
- no change to the current workflow of people (submodules are only needed for CI - you only need submodules if you want to update to newer version of the actions
- GitHub has full support for review for submodules. When action is updated, reviewer will see diff of incoming changes that can be reviewed as usual (also part of security guidelines to review changes to actions rigorously)
- no 3rd-party code in superset repo
There are no drawbacks that I am aware of.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@amitmiran137 @ktmud Can you look at it?
This is great. Thanks for making this change! |
We actually used @potiuk 's potius/cancel-workflow-runs for the |
FYI. I do recommend to migrate it to submodule as well, however my action was allow-listed by INFRA so you can use it directly ;) |
My change is the fix and improvement for github action which labels approved PRs (introduced in this [PR](#6239)). It is inspired by solution introduced and tested in [Apache Airflow](https://github.com/apache/airflow) (thanks @potiuk @ashb 🚀 ) Corresponding Apache Airflow workflows on which I based this PR: - https://github.com/apache/airflow/blob/main/.github/workflows/label_when_reviewed.yml - https://github.com/apache/airflow/blob/main/.github/workflows/label_when_reviewed_workflow_run.yml Problems which were solved in this PR: - **Permissions**. @morningman opened a related bug: [[Help] Error: Resource not accessible by integration](TobKed/label-when-approved-action#7). It is related to limited permissions of workflows being triggered by `pull_request_review` (`GITHUB_TOKEN` has read-only permissions). More information about it you can find in the article: [Keeping your GitHub Actions and workflows secure: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/). TL;DR: On pull request review event (`on: pull_request_review` ) "dummy" workflow `Label when reviewed` triggers another workflow `Label when approved workflow run` which has sufficient permissions (`on: workflow_run: workflows: ["Label when reviewed"]`). - **Safe use of 3rd-party Github Actions by using submodules pattern.** It is decribed in: https://cwiki.apache.org/confluence/display/BUILDS/GitHub+Actions+status > NEVER use 3rd-party actions directly in your workflows - use the "submodule" pattern. This pattern is successfully used by projects like: - [Apache Airflow](https://github.com/apache/airflow) ([PR](apache/airflow#13514)) - [Apache Beam](https://github.com/apache/beam) ([PR](apache/beam#13736)) - [Apache Superset](https://github.com/apache/superset) ([PR](apache/superset#12709))
SUMMARY
The idea was to improve GitHub Actions after ASF changed the rules and only allow
actions hosted in-organization.
IMHO using git submodules is more clean way to use external github actions.
I based my opinion this on the discussion:
https://lists.apache.org/x/thread.html/r435c45dfc28ec74e28314aa9db8a216a2b45ff7f27b15932035d3f65@%3Cbuilds.apache.org%3E
and how it was solved in:
List of repositories added as git submodules with their revisions:
EndBug/latest-tag@latest
morrisoncole/pr-lint-action@v1.4.1
trilom/file-changes-action@v1.2.4
styfle/cancel-workflow-action@0.6.0
apache-superset/cached-dependencies@b90713b
unsplash/comment-on-pr@v1.2.0
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
TEST PLAN
ADDITIONAL INFORMATION