Scope of the Github action

[LecrisUT]

Description

Right now the only implementation visible is to create srpms, for which the user cannot find much application for. I want to flush out what the full implementation of the GH action should be and how it could be used in the future.

Overall the idea is that packit application is the main intermediator and the default implementation if no GH action is setup, while packit GH action is the way to get fine-grained control of each operation.

Github action

All packit actions available in the cli and packit-service should be implemented as separate actions (rtd/actions for reference). If in the specific commit associated with a trigger, it is detected that a github workflow contains any of these GH actions, then do not trigger packit application workflow, but instead wait for the workflow to trigger them (either directly via packit cli, or indirectly by calling packit-service somehow). Otherwise default to the packit application workflows.

Benefits

• fine-grained control of the workflow
• reduced build requests
• piggy-back onto GH action workflows (solves issues like propose-downstream: adjust retries to consider waiting for actions packit#1954, Supporting [skip ci] and [ci skip] in the commit message packit#1987)

Example interface

jobs:
  normal-test:
    ...
  packaging-test:
    needs: [ normal-test ]
    steps:
      - uses: packit/actions/build_copr@latest
        with:
          targets: [ fedora-development ]
      - uses: packit/actions/test@latest
        with:
          targets: [ fedora-development ]

Implementation considerations

• Should all jobs: in .packit.yaml be ignored and require them to be defined within GH action?
  (if in the commit/PR it is detected that there exists at least one uses: packit/actions, otherwise use default packit app logic)
• Should the packit action version be synchronized with the packit cli, or should it be adjustable via with:version:...?
  If the former, it would be better to move these directly in packit/packit, that way PRs and fork versions can be tested more easily.

What needs to be implemented

• packit-action: packit_setup
  - Basically run: (python_setup if a python version is passed + ) pip install packit with appropriate cachings
  - Other actions might be necessary, e.g.: converting a base64 secret to a kerberos identity
  - This might or might not be necessary depending on what backend we want to use, i.e. it is not necessary if we make the actions as container actions.
  - The only thing concerning me here is, how will it behave in nested container or in combination with other actions. Defining this action instead of using containers would guarantee there is no clashing
• packit-action: srpm
  - Simply run packit srpm and uploading the artifacts if needed
• packit-action: build_copr
  - Trigger packit build in-copr
  - Requires setting up appropriate authenthication
  - Need to research how to properly interact with timeout to allow for long runs and report progress
  - Using nodeJS action would be helpful for this one
• packit-action: test
  - No available packit command. Basically given a previous build_copr ID, trigger the appropriate testing-farm interface
  - Probably useful: https://github.com/sclorg/testing-farm-as-github-action
  - Requires setting up appropriate authenthication. Rather tricky, because do we authenticate as User or Packit? If the later how could we do that safely?
• packit-action: propose_downstream
  - Run packit propose_downstream --local-content
  - Requires setting up appropriate authenthication

[lachmanfrantisek]

I am moving this to the packit/packit-service#1097 epic and making this the first card to work on.

[LecrisUT]

I've updated the top-level comment. The main difficulty is with packit_setup + the authenthication.

Backend wise, I think it would be better to make it without the use of container (i.e. composite (and noeJS) actions), that way, it would be easier to specify specific versions of packit more easily.