We have a configuration file with multiple Packit-triggered jobs. It would be nice if both the packages were installed into the testing farm evnironment and tested.
Once the monorepo functionality is real in Packit, this will become more important.
It would be best if we could specify what package names should be installed (e.g. mock and mock-core-configs) and if only one of them is updated (say mock) and thus built in Copr (the other build is optimized out), we would install one of those packages from normal distribution (mock-core-configs) and the other from Copr (the freshly built mock).environment
Benefit
A convenient useability pattern. Alternatively, we could have documentation on how to handle such a use case.
Importance
If there's no work-around, this is a must to make testing-farm usable through Packit with mono-repositories.
What is the impacted category (job)?
Testing Farm tests
Workaround
[ ] There is an existing workaround that can be used until this feature is implemented.
Participation
[ ] I am willing to submit a pull request for this issue. (Packit team is happy to help!)
Description
We have a configuration file with multiple Packit-triggered jobs. It would be nice if both the packages were installed into the testing farm evnironment and tested.
Once the monorepo functionality is real in Packit, this will become more important.
It would be best if we could specify what package names should be installed (e.g.
mock
andmock-core-configs
) and if only one of them is updated (saymock
) and thus built in Copr (the other build is optimized out), we would install one of those packages from normal distribution (mock-core-configs
) and the other from Copr (the freshly builtmock
).environmentBenefit
A convenient useability pattern. Alternatively, we could have documentation on how to handle such a use case.
Importance
If there's no work-around, this is a must to make testing-farm usable through Packit with mono-repositories.
What is the impacted category (job)?
Testing Farm tests
Workaround
Participation