Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not generate database entry from the event for Anitya / New Hotness #2440

Closed
Tracked by #2068
mfocko opened this issue Jun 6, 2024 · 0 comments · Fixed by #2524
Closed
Tracked by #2068

Do not generate database entry from the event for Anitya / New Hotness #2440

mfocko opened this issue Jun 6, 2024 · 0 comments · Fixed by #2524
Assignees
Labels
area/fedora Related to Fedora ecosystem area/rhel-ecosystem RHEL & CentOS stream complexity/single-task Regular task, should be done within days. gain/high This brings a lot of value to (not strictly a lot of) users. impact/high This issue impacts multiple/lot of users. kind/technical-debt The code needs love. Refactoring.

Comments

@mfocko
Copy link
Member

mfocko commented Jun 6, 2024

Part of #2106

Currently we generate a database entry from the event:

) = ProjectEventModel.add_release_event(
tag_name=self.tag_name,
namespace=self.repo_namespace,
repo_name=self.repo_name,
project_url=self.project_url,
commit_hash=None,
)

This is a problematic state, cause when we start reacting to Anitya, we can receive multiple versions (not just the latest one as for the Rawhide) from which we then choose one based on to-be implemented rules or version mask defined by the user.

Move this functionality out of the event, as the tight-coupling of event × DB entry doesn't make sense in this case.

Be careful about the consequences of this action, i.e., database being populated by calling the _add_* on the events.

Note

Alternative approach could be populating the tag name in DB with a dummy value that would be overwritten in the handler in later stages, instead of creating the database entry later by the handler.

@mfocko mfocko added kind/technical-debt The code needs love. Refactoring. area/fedora Related to Fedora ecosystem complexity/single-task Regular task, should be done within days. impact/high This issue impacts multiple/lot of users. gain/high This brings a lot of value to (not strictly a lot of) users. area/rhel-ecosystem RHEL & CentOS stream labels Jun 6, 2024
@lachmanfrantisek lachmanfrantisek moved this from new to priority-backlog in Packit Kanban Board Jun 6, 2024
@mfocko mfocko moved this from priority-backlog to refined in Packit Kanban Board Jul 18, 2024
@lbarcziova lbarcziova self-assigned this Sep 4, 2024
@lbarcziova lbarcziova moved this from refined to in-progress in Packit Kanban Board Sep 4, 2024
lbarcziova added a commit to lbarcziova/packit-service that referenced this issue Sep 11, 2024
@lbarcziova lbarcziova moved this from in-progress to in-review in Packit Kanban Board Sep 11, 2024
lbarcziova added a commit to lbarcziova/packit-service that referenced this issue Sep 13, 2024
lbarcziova added a commit to lbarcziova/packit-service that referenced this issue Sep 13, 2024
softwarefactory-project-zuul bot added a commit that referenced this issue Sep 19, 2024
Create model for multiple Anitya versions

Fixes #2440
Discussed with @mfocko that we can store the multiple versions in the DB.
RELEASE NOTES BEGIN
N/A
RELEASE NOTES END

Reviewed-by: Maja Massarini
Reviewed-by: Laura Barcziová
@github-project-automation github-project-automation bot moved this from in-review to done in Packit Kanban Board Sep 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/fedora Related to Fedora ecosystem area/rhel-ecosystem RHEL & CentOS stream complexity/single-task Regular task, should be done within days. gain/high This brings a lot of value to (not strictly a lot of) users. impact/high This issue impacts multiple/lot of users. kind/technical-debt The code needs love. Refactoring.
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

2 participants