-
Notifications
You must be signed in to change notification settings - Fork 49
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
Add more customizable details to failure comments #2245
Conversation
Build failed. ✔️ pre-commit SUCCESS in 1m 57s |
There was a problem hiding this 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
packit_service/constants.py
Outdated
"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", |
There was a problem hiding this comment.
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}
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 😅?
There was a problem hiding this comment.
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
)...
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
"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", |
There was a problem hiding this comment.
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?
# 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 |
There was a problem hiding this comment.
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"
?
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 thanNone/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 (withno entry ...
as default) and avoid catching of theKeyError
.
There was a problem hiding this comment.
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.
packit_service/constants.py
Outdated
"commit_sha", | ||
"copr_build_packit_info", | ||
"srpm_build_packit_info", | ||
"copr_build_logs", |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
Build failed. ❌ pre-commit FAILURE in 1m 49s |
b6e7faf
to
15e0ad1
Compare
Build failed. ✔️ pre-commit SUCCESS in 25m 52s |
There was a problem hiding this 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.
packit_service/constants.py
Outdated
"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}", |
There was a problem hiding this comment.
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}
?
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) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
Co-authored-by: Laura Barcziová <[email protected]>
15e0ad1
to
d7ea2de
Compare
Build failed. ✔️ pre-commit SUCCESS in 1m 52s |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nicely done!
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
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 jobpackit_dashboard_url
: Packit dashboard url for the jobexternal_dashboard_url
: service dashboard url; Copr, Koji or Testing Farm service depending on the Packit jobRELEASE NOTES END