-
Notifications
You must be signed in to change notification settings - Fork 18
GitHub Actions #112
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
base: main
Are you sure you want to change the base?
GitHub Actions #112
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,87 @@ | ||
| # GitHub Actions | ||
|
|
||
| ## Benefits and options for Packit and users of Packit | ||
|
|
||
| ### Customization as a whole | ||
|
|
||
| In case of providing Packit API via GitHub Actions it allows to run pipeline (SRPM → Copr → | ||
| Testing Farm) after: | ||
|
|
||
| - running some initial CI checks (saves resources on our side) | ||
| - preparing archives (eliminates need for retries and failed jobs on our side, if they are blocked | ||
| by some external action) | ||
|
|
||
| ### SRPM builds | ||
|
|
||
| - Allows user to **easily** customize the dependencies, i.e. does not require changes to be made to | ||
| the Sandcastle image. | ||
| - Provides access to created SRPMs without dependency on Copr or Packit Service. | ||
|
|
||
| ## Disadvantages and caveats | ||
|
|
||
| ### SRPM builds | ||
|
|
||
| - If we were to trigger Copr builds with SRPM created in GitHub Action we introduce blocking action of | ||
| acquiring the SRPM from GitHub. | ||
| - No cache is present, which also introduces: | ||
| - slower build time | ||
| - potential time out, since Actions are time limited (iirc 24 hrs per action) | ||
|
Comment on lines
+26
to
+28
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. this is a good point, since job scheduling would be completely out of our control |
||
|
|
||
| ### Security concerns | ||
|
|
||
| In case of utilizing API via GitHub Actions there is a risk of modifying actions that could result | ||
| in leaking of the secrets. GitHub mitigates this by censoring the output of GitHub Actions, but with | ||
| our use-case it would be still possible to (indirectly) modify scripts that are run and leak the | ||
| secrets. | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Secrets shouldn't be available during pull-request workflows ... and push workflows are fully under the maintainer's control.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is handy but will probably cause problems with the Copr builds for PRs. How we can do this?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ad pull request workflow, they disable secrets by default (with an override): https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#potential-impact-of-a-compromised-runner In ideal case I would like to split the action to multiple parts and pass the secrets to the environment only for calling packit that directly queries API. Follow-up question:
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I think so, but if we want to change this and reuse the existing SRPM, this is easy to do. Maybe as another CLI argument? |
||
|
|
||
| Possible options how to prevent this are: | ||
|
|
||
| - inject secrets after running all customizable actions | ||
| - do not run the action if user has no write-access (enforces check by the maintainer) | ||
| - differentiating «maintainer approved»? | ||
| - how to decide if changes can be evaluated or not? (i.e. user is trusted to modify the files) | ||
| - list of files that cannot be modified externally? However it might be required to get those | ||
| from the default branch, since branch where changes are merged may be compromised. | ||
|
|
||
| ### Versioning | ||
|
|
||
| In case we do not provide specialized images on which Packit can be run, we can run into issues with | ||
| different versions of Packit being used (RPM vs PyPI vs images). | ||
|
Comment on lines
+48
to
+49
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm afraid we'd need to provide packit in a container where the env is in full control from us |
||
|
|
||
| ## How can we use it | ||
|
|
||
| ### SRPM build | ||
|
|
||
| _TODO_ | ||
|
|
||
| ### Local RPM build | ||
|
|
||
| _TODO_ | ||
|
|
||
| ### Mock RPM build | ||
|
|
||
| _TODO_ | ||
|
|
||
| ### Copr RPM build | ||
|
|
||
| _TODO_ | ||
|
|
||
| ### Testing Farm | ||
|
|
||
| _TODO_ | ||
|
|
||
| #### Running tests in GitHub Action | ||
|
|
||
| _TODO_ | ||
|
|
||
| #### Testing farm via API from GitHub Action | ||
|
|
||
| _TODO_ | ||
|
Comment on lines
+77
to
+79
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ideally, leave this to the Testing Farm team (=Miro) and allow some integration. |
||
|
|
||
| ### Rough estimation of time required | ||
|
|
||
| _TODO_ | ||
|
|
||
| ## Sharing the work done with GitLab (and potentially Pagure) | ||
|
|
||
| _TODO_ | ||
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.
we could potentially trigger p-s' API from the action and POST the SRPM
would be interesting to discuss alternative solutions for this step