Inconsistent behaviour for source files given by create_archive for top-level actions and job actions

[pirat89]

We have realized the top-level actions & job actions have a different behaviour regarding the sources. We know it's documented the sources have to be present in the same directory as the SPEC file, but in case they are present a subdir instead (e.g. SOURCES), PackIt works in case of the top-level actions, and crashes in case of the job actions. E.g.:

actions:
  create-archive:
  - bash -c "rm -f packaging/*.tar.gz"
  - bash -c "make source"
  - bash -c "find packaging/*.gz -type f"

jobs:
- job: copr_build
  trigger: pull_request
  metadata:
    owner: "@oamg"
    project: leapp
    targets:
    - epel-7-x86_64
    - epel-8-x86_64
  actions:
    create-archive:
    - bash -c "rm -f packaging/*.tar.gz"
    - bash -c "make source"
    - bash -c "find packaging/*.gz -type f"

In both cases, multiple source files are under the packaging/sources/ directory (the removal points to a different path to ensure the files are not present in the same directory).

See the following file for better context (removing the "mv" commands shows the behaviour differences; currently it's working):

• https://github.com/oamg/leapp-repository/blob/master/.packit.yaml

Expected result:

• consistent behaviour regarding the source files is same regardless the top-level or nested (job) actions; read: require source files in the same directory as the SPEC file, or accept given source files from other directories as well

Additional info:

• we are aware the job copr_build is not executed when we call packit srpm from the CLI. We discovered the different behaviour when putting the create-archive action the top-level and then under the job on the github directly and we checked that all commands in the create-archive action have been really called in both cases. When nested, tarballs are not discovered by packit.

[stale]

This issue has been marked as stale because it hasn't seen any
activity for the last 60 days.

Stale issues are closed after 14 days, unless the label is removed
by a maintainer or someone comments on it.

This is done in order to ensure that open issues are still relevant.

Thank you for your contribution! 🦄 🚀 🤖

(Note: issues labeled with pinned or EPIC are
never marked as stale.)

[pirat89]

I think this issue is worthy to solve

[stale]

This issue has been marked as stale because it hasn't seen any
activity for the last 60 days.

Stale issues are closed after 14 days, unless the label is removed
by a maintainer or someone comments on it.

This is done in order to ensure that open issues are still relevant.

Thank you for your contribution! 🦄 🚀 🤖

(Note: issues labeled with pinned or EPIC are
never marked as stale.)

[TomasTomecek]

Agreed, this should be resolved.

[stale]

This issue has been marked as stale because it hasn't seen any
activity for the last 60 days.

Stale issues are closed after 14 days, unless the label is removed
by a maintainer or someone comments on it.

This is done in order to ensure that open issues are still relevant.

Thank you for your contribution! 🦄 🚀 🤖

(Note: issues labeled with pinned or EPIC are
never marked as stale.)

[TomasTomecek]

We have recently discussed this issue that the behaviour should be changed so that you don't need to copy-pasta the actions that should be inherited.

[stale]

This issue has been marked as stale because it hasn't seen any
activity for the last 60 days.

Stale issues are closed after 14 days, unless the label is removed
by a maintainer or someone comments on it.

This is done in order to ensure that open issues are still relevant.

Thank you for your contribution! 🦄 🚀 🤖

(Note: issues labeled with pinned or EPIC are
never marked as stale.)