Feat/centos anitya #2348
Feat/centos anitya #2348
Conversation
|
Build failed. ✔️ pre-commit SUCCESS in 2m 23s |
| return None | ||
|
|
||
| # FIXME: Handle Fedora too in case we want to support multiple releases | ||
| # such as for Go. |
There was a problem hiding this comment.
There was an RFE for this on the Slack already…
There was a problem hiding this comment.
+1, we can create a separate issue for this (e.g.this will imply monitoring settings for the package will not be considered anymore, therefore also changes in documentation etc.)
we could properly test this for CentOS Stream and once it is tested to be working do the switch for Fedora packages to not break anything for already onboarded Fedora packages
| self._versions = versions | ||
|
|
||
| @property | ||
| def version(self) -> str: |
There was a problem hiding this comment.
The major issue here is that we “generate” DB entry for the release from the event object. There's also serialization involved (for Celery).
At the same time it feels a bit weird to keep logic of “deciding the next version” in the »event«.
There was a problem hiding this comment.
discussed together with Mato that we want all the new versions, see e.g. https://apps.fedoraproject.org/datagrepper/v2/id?id=efec10ed-9f86-4e03-9e4f-2e626934b3ae&is_raw=true&size=extra-large in here we would be interested in all 3
There was a problem hiding this comment.
and then it is up to maintainer to define the per-branch jobs and rules (e.g. via version_udpate_mask, upstream_tag_include, upstream_tag_exclude): example
and default would be the "latest greatest"
| # we going to choose the version? | ||
| # a) latest greatest | ||
| # b) next unreleased? | ||
| # this can be also influenced by the mask… |
There was a problem hiding this comment.
Example of a problem:
- There's a
1.0.0release in Fedora. - We've got releases
1.0.1,1.1.0and2.0.0from Anitya - Which release do we sync? The next possible (
1.0.1) or latest-greatest2.0.0? Syncing all of them would create a lot of noise. - Ideal scenario here would be having the version mask defined, so it would be as explicit as possible.
|
recheck |
|
Build failed. ❌ pre-commit FAILURE in 2m 35s |
mfocko
force-pushed
the
feat/centos-anitya
branch
from
375680b
to
d45eac8
Compare
|
Build failed. ✔️ pre-commit SUCCESS in 2m 26s |
mfocko
force-pushed
the
feat/centos-anitya
branch
from
d45eac8
to
6f3b4ed
Compare
|
Build succeeded. ✔️ pre-commit SUCCESS in 2m 20s |
|
Build succeeded. ✔️ pre-commit SUCCESS in 2m 27s |
mfocko
force-pushed
the
feat/centos-anitya
branch
from
8a31086
to
11dc3b6
Compare
|
Build succeeded. ✔️ pre-commit SUCCESS in 2m 24s |
|
@lbarcziova rebased, added test case; left notes in comments (code) and also updated the original description; this should be ready for review and merge |
Signed-off-by: Matej Focko <[email protected]>
Signed-off-by: Matej Focko <[email protected]>
There are still some parts that will be done in the follow-up PRs, so don't run at all for version update (affects no one, as it hasn't been merged yet). Signed-off-by: Matej Focko <[email protected]>
Signed-off-by: Matej Focko <[email protected]>
Signed-off-by: Matej Focko <[email protected]>
Signed-off-by: Matej Focko <[email protected]>
mfocko
force-pushed
the
feat/centos-anitya
branch
from
11dc3b6
to
163591f
Compare
|
Build succeeded. ✔️ pre-commit SUCCESS in 2m 15s |
|
Build succeeded (gate pipeline). ✔️ pre-commit SUCCESS in 2m 33s |
softwarefactory-project-zuul
bot
merged commit 623c117
into
packit:main
Related to #2068