Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
87 changes: 87 additions & 0 deletions github-actions/README.md
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.
Comment on lines +24 to +25
Copy link
Member

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

- 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
Copy link
Member

Choose a reason for hiding this comment

The 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.

Choose a reason for hiding this comment

The 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.

Copy link
Member

Choose a reason for hiding this comment

The 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?

Copy link
Member Author

Choose a reason for hiding this comment

The 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:

  • Do we always create SRPM for packit copr-build, even if there is an SRPM already present?

Copy link
Member

@lachmanfrantisek lachmanfrantisek Oct 21, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

* Do we **always** create SRPM for `packit copr-build`, **even if** there is an SRPM already present?

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
Copy link
Member

Choose a reason for hiding this comment

The 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
Copy link
Member

Choose a reason for hiding this comment

The 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_