Laura Barcziová
Laura Barcziová
The problem is when processing the New Hotness event initially, we take the `upstream_tag_template` from the whole package config: https://github.com/packit/packit-service/blob/ff6c0f5f4ae9e51311fb8e195d2b2df3d325c4ac/packit_service/worker/events/new_hotness.py#L130-L134. An example of a failure caused by this: https://dashboard.packit.dev/results/pull-from-upstream/4757 (config:...
Since for test jobs, builds may be required, we additionally don't allow builds if there is an internal TF test job with the same trigger configured (builds could trigger the...
The outcome of this card will be that users will be able to explicitly configure dependencies between jobs => reference which job needs to be run before some other job....
- [ ] use the implementation from packit/packit#2147 (initialise PackitAPI for pull-from-upstream with `non_git_upstream=True` if `upstream_project_url` is None in package config) - [ ] figure out the DB event handling...
just verifying https://github.com/packit/packit.dev/issues/607
Related to #1803: we want to reformulate the Testing Farm related SLO in a following way: „Test runs have set success/failure in X (TBD) minutes, **after the test has finished**“...
Related code: https://github.com/packit/packit-service/blob/3531669ee87997c0045885c859fa1bb7d43782a3/packit_service/worker/handlers/distgit.py#L443-L457 If it is not possible to download the archive at least for one of the branches, all the branches are being retried no matter whether they ran...
When Packit Service creates issues for downstream job failures (specifically for `koji-build` and `bodhi-update`) and the `issue_repository` configured by the user is hosted in GitHub, we currently use the authentication...
When a Koji build fails to be triggered, user is not really informed about the cause of the failure: - dashboard [example](https://dashboard.stg.packit.dev/results/koji-builds/463) - issue [example](https://github.com/packit/ogr/issues/851)