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

Add more customizable details to failure comments #2245

Merged
merged 1 commit into from
Nov 6, 2023

Conversation

majamassarini
Copy link
Member

@majamassarini majamassarini commented Nov 3, 2023

Fixes #2196
Merge before packit/packit.dev#769


RELEASE NOTES BEGIN

User can now further customize comment messages (written by Packit as a reaction of a failed job). The user can include in the customized message the following new placeholders:

  • logs_url: service's logs url; Copr, Koji or Testing Farm service depending on the Packit job
  • packit_dashboard_url: Packit dashboard url for the job
  • external_dashboard_url: service dashboard url; Copr, Koji or Testing Farm service depending on the Packit job

RELEASE NOTES END

Copy link
Contributor

Copy link
Member

@lbarcziova lbarcziova left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice job! Only one question regarding the variable naming

Comment on lines 268 to 274
"copr_build_packit_info",
"srpm_build_packit_info",
"copr_build_logs",
"koji_build_packit_info",
"koji_build_logs",
"testing_farm_packit_info",
"testing_farm_logs",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am wondering if we could consolidate these only to something like packit_dashboard_url and logs_url 🤔 e.g. when someone configures a Copr build job, it can fail either in the SRPM phase or Copr build itself and it would be probably easier for user to configure only something like

One of the Copr builds failed for commit {commit_sha}, ping @admin, packit dashboard: {packit_dashboard_url}, logs: {logs_url}

Copy link
Member

@lachmanfrantisek lachmanfrantisek Nov 3, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am on the fence here if we should support both specific and generic ones or just the generic ones.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean for the generic ones 😅?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean for the generic ones 😅?

Sorry, I didn't know how to call the ones Laura suggested -- like logs_url (unlike the "specific" ones like copr_build_url)...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking more about it I agree with Laura, the user can't really use in a message logs_url coming from different services or a packit_dashboard_url for a different job... For this reason I think we don't need to differentiate them and we can make life easier for the user having only two placeholders: packit_dashboard_url and logs_url.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 Makes sense -- and we can easily add more if people ask for that.

Copy link
Member

@lachmanfrantisek lachmanfrantisek Nov 6, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe, I would provide and differentiate also (not sure about the names) web_url and logs_url. (We have both for Copr -- on links to Copr frontend view, one to log.)

edit: OK, Just seen your comment bellow...

packit_service/constants.py Outdated Show resolved Hide resolved
Comment on lines 268 to 274
"copr_build_packit_info",
"srpm_build_packit_info",
"copr_build_logs",
"koji_build_packit_info",
"koji_build_logs",
"testing_farm_packit_info",
"testing_farm_logs",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about using a url suffix for all the links?

Comment on lines 777 to 779
# every detail (the user would like to have)
# could be missing in the calling job
# iterate over all the details until we can build the user string
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since you have a name of all the keys, can't we specify all and the unknown to None/"unknown"?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But I like you are trying to resolve this situation.

Also, it would be nice to cover this in the tests...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I am not following you. There exist a test for the situation, I wrote the code using the test. Or I don't understand which situation do you mean 😅.
Regarding the first hint, I thought that a message like copr build logs {no entry for copr_build_packit_info} can be more understandable for the user than copr build logs None/unknown but maybe I did not understand your suggestion?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mixed multiple points here...;)

Tests:

  • My bad, I missed that test-case. Sorry.

Wording:

  • I agree {no entry for copr_build_packit_info} is better than None/unknown. => I like the UX.

Code:

  • That was my main point if we can't do this in a "less technical" way. (Or, how to describe it.) Since we have the list of all the possible variables defined in constants.py, we can always provide all the variables to the formatted (with no entry ... as default) and avoid catching of the KeyError.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, now I understand and I agree.

"commit_sha",
"copr_build_packit_info",
"srpm_build_packit_info",
"copr_build_logs",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With Copr, we differentiate logs URL and web URL. This would be nice to cover as well.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I go with the Laura's suggestion, then I can think to have 3 links:

packit_dashboard_url
logs_url
external_dashboard_url -> the copr web url can be linked here? And maybe also the koji dashboard build detail, that I think we have?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, something like that would be nice.

Copy link
Contributor

@majamassarini majamassarini force-pushed the fix/packit-service/2196 branch from b6e7faf to 15e0ad1 Compare November 6, 2023 12:03
Copy link
Contributor

Copy link
Member

@lachmanfrantisek lachmanfrantisek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! Just one small suggestion.

"commit_sha": "{no entry for commit_sha}",
"packit_dashboard_url": "{no entry for packit_dashboard_url}",
"external_dashboard_url": "{no entry for external_dashboard_url}",
"logs_url": "{no entry for logs_url}",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't we generate the failure message automatically if it's just {no entry for $VALUE}?

Comment on lines +771 to +774
all_kwargs = copy.copy(FAILURE_COMMENT_MESSAGE_VARIABLES)
all_kwargs["commit_sha"] = self.db_project_event.commit_sha
all_kwargs.update(kwargs)
formatted_message = configured_message.format(**all_kwargs)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@majamassarini majamassarini force-pushed the fix/packit-service/2196 branch from 15e0ad1 to d7ea2de Compare November 6, 2023 13:07
Copy link
Contributor

@majamassarini majamassarini merged commit 188ae23 into packit:main Nov 6, 2023
Copy link
Member

@lbarcziova lbarcziova left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nicely done!

softwarefactory-project-zuul bot added a commit to packit/packit.dev that referenced this pull request Nov 10, 2023
Add more customizable details for comment failures

Merge after packit/packit-service#2245

Reviewed-by: František Lachman <[email protected]>
Reviewed-by: Laura Barcziová
Reviewed-by: Maja Massarini
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support for linking copr builds in github comment notifications
3 participants