Repository navigation
Inconsistent behaviour for source files given by create_archive for top-level actions and job actions #569
Description
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):
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_buildis not executed when we callpackit srpmfrom the CLI. We discovered the different behaviour when putting thecreate-archiveaction the top-level and then under the job on the github directly and we checked that all commands in thecreate-archiveaction have been really called in both cases. When nested, tarballs are not discovered by packit.
Activity
stale commentedon Mar 2, 2022
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 commentedon Mar 2, 2022
I think this issue is worthy to solve
stale commentedon May 1, 2022
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 commentedon Jun 1, 2022
Agreed, this should be resolved.
stale commentedon Jul 31, 2022
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 commentedon Aug 3, 2022
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 commentedon Nov 2, 2022
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.)
majamassarini commentedon Mar 19, 2026
Still relevant.