-
Notifications
You must be signed in to change notification settings - Fork 185
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
Enhanced changelog validation #7942
Conversation
672bf7c
to
b1ffb4b
Compare
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 a lot for the work, this looks nice already! You've done a great job with the test suite to show the different validations!
I left a few comments in line, most of them are just informational (about Python). Other than that, I have a general remark:
Can we move the user documentation from the PR description to its own file? It'll be easier to reference it in the future (e.g. when running the code locally). BTW, python3 .github/workflows/changelogs/changelogs.py $(git diff --name-only origin/master...HEAD)
can be used to pass all files to the script (assuming a. the remote is called origin and b. you want to merge into master).
if not files["files"]: | ||
# Changelog added but no file is modified | ||
issues.append(Issue(IssueType.WRONG_CHLOG, package=pkg)) |
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.
Could this happen intentionally? E.g. when we forgot a (second) tracker and want to add it afterwards
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.
Sure, but I think it's better fixed with an explicit approval from rel-eng. The test itself should fail anyway.
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 agree. in general we should not edit old changelogs. if this happen it should be only for good reasons. and if we add additional bsc we (releng) need to also be sure that the related patchinfo will also include that reference in a different way from a standard fixed bsc.
@juliogonzalez / @raulillo82 what's your take?
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, makes sense.
Note 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.
@cbbayburt I left a comment about the available trackers.
bug = self.bzapi.getbug(bug_id) | ||
logging.debug(f"Bug #{bug_id} belongs to product '{bug.product}'") | ||
|
||
if not bug.product.startswith("SUSE Manager"): |
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, for security the product is called
SUSE Security Incidents
parser.add_argument("-t", "--tracker-file", | ||
help="tracker definitions XML document retrieved from the OBS/IBS API. Bypass tracker validation if not provided.") |
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.
Please, keep in mind that we have some trackers in IBS not available in OBS.
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 compared them, and it seems there are only minor differences in between. Which one should we use? OBS for Uyuni, and IBS for SUSE Manager? or something else?
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 compared them, and it seems there are only minor differences in between. Which one should we use? OBS for Uyuni, and IBS for SUSE Manager? or something else?
the easy way it could also be to switch between Uyuni / OBS and SUMA / IBS
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 it's true that for using IBS we will need authentication. 🤔
in any case, IBS has all the trackers available in OBS, if the parsed tracker is valid in OBS it'svalid in IBS too. let's start easy
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.
OBS also requires authentication 🤷🏻♂️
So we either create an account and store credentials in GitHub, or we update the file manually whenever needed.
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.
before uploading that list we need to check why also this endpoint requires authentication :(
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.
There's nothing risky in the data so my guess is it's just the default way the API is designed. But let's ask and make sure of course.
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.
@deneb-alpha thanks for opening the OBS issue. IIUC from this comment, it's ok to upload it to our public repo.
Thanks, @agraul for the review and all the tips. I'll address them all separately.
Good idea, I'll add it in a README in the directory. |
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.
left few more comments
bug = self.bzapi.getbug(bug_id) | ||
logging.debug(f"Bug #{bug_id} belongs to product '{bug.product}'") | ||
|
||
if not bug.product.startswith("SUSE Manager"): |
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.
it could also be that a bsc under SUSE Security Incidents
could also be restricted. I think we could start checking only for SUMA and enhance this later
if not files["files"]: | ||
# Changelog added but no file is modified | ||
issues.append(Issue(IssueType.WRONG_CHLOG, package=pkg)) |
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 agree. in general we should not edit old changelogs. if this happen it should be only for good reasons. and if we add additional bsc we (releng) need to also be sure that the related patchinfo will also include that reference in a different way from a standard fixed bsc.
@juliogonzalez / @raulillo82 what's your take?
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.
how often we will refresh this xml file?
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.
In the current state, it needs to be manually uploaded. I don't think this data gets updated often so it shouldn't be much of a problem.
I was also thinking about requesting it from the action itself and caching it, but it seems that the /issue_trackers
endpoint needs authentication, so for that, we need to set up an OBS account and store the credentials as additional secrets in Github. All this seems like more work than just manually uploading it. Also, since IBS is not reachable from here, we can only do this for OBS.
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.
@cbbayburt from my side +1.
but let's also check with the team if they have issues with what will be marked as failure and what only as warning.
parser.add_argument("-t", "--tracker-file", | ||
help="tracker definitions XML document retrieved from the OBS/IBS API. Bypass tracker validation if not provided.") |
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 it's true that for using IBS we will need authentication. 🤔
in any case, IBS has all the trackers available in OBS, if the parsed tracker is valid in OBS it'svalid in IBS too. let's start easy
.github/workflows/changelogs.yml
Outdated
runs-on: ubuntu-latest | ||
steps: | ||
- uses: actions/checkout@v4 | ||
with: | ||
fetch-depth: 1 | ||
fetch-depth: 2 |
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.
Just out of curiousity, why 2
?
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.
One comment about the credentials.
if: steps.changelogs.conclusion == 'success' && steps.changelogs.outputs.added_modified == '' | ||
- name: Test changelog entries | ||
env: | ||
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} |
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 this won't work on forks, as the credentials won't be present there, so we'll have the same problem we had for SonarQube? @cbosdo, am I right about this one?
This PR is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 10 days. |
This PR is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 10 days. |
This PR is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 10 days. |
ef24e5e
8b4660c
to
ef24e5e
Compare
cb76be1
to
921c0e4
Compare
a9b7b94
to
ab0d518
Compare
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.
@cbbayburt for now I think it LGTM
* Use 'dataclasses' * Use python3 shebang * Use re.match to match beginning * Remove 'type' keyword usages * Use 'setdefault' * Remove 'wrong capitalization after colon' test * Rename 'spacewalk_dir' to 'uyuni_dir' * Use 'enumerate' in main loop * Fix line numbers off-by-one issue * Simplify runner code
0ef543f
to
bd133a3
Compare
A complete overhaul of the changelog validation workflow, introducing many enhancements over the existing GitHub action.
Features
.github/workflows/changelogs/changelogs.py
)bugzilla.suse.com
.github/workflows/changelogs/trackers.xml
)changelogs.py
directly (See "How to run locally" below)Bugzilla access and tracker information
To enable tracker validation through Bugzilla, we need a Bugzilla API key as a repository secret in
uyuni-project/uyuni
. The code usespython-bugzilla
client and requests a bug via its ID to retrieve its product name.If the API key is not set up in Github, the Bugzilla checks are skipped.
Tracker information is provided with the
trackers.xml
file included in the PR. This file is retrieved from the OBS API endpoint/issue_trackers
.GUI Diff
Console output
Inline reporting in GUI
How to run locally
Note: To run the script, you need to have the
gh
(GitHub CLI tool) and thepython-bugzilla-3.2.0
library installed.Basic functionality
Once you finish working on your feature and add the necessary changelog entries, execute the following command from your Uyuni repository root, providing all your modified files including the changelog files as positional arguments:
python .github/workflows/changelogs/changelogs.py $(git diff --name-only <pr_base_rev>..<pr_head_ref>)
Since no PR or tracker information is provided, PR and tracker validation will be skipped.
Full validation (PR, trackers, Bugzilla, etc.)
If you have any trackers (bsc#xxx, etc.) mentioned in your changelogs, PR title, and/or commit messages, you should enable the additional checks as well. To do that, add a PR number and a tracker file to the command using the corresponding arguments:
If you want to validate a PR in a different fork, you can specify any Uyuni fork using the
--git-repo
argument.Below is a full list of available arguments, their usages, and default values:
More information
Check out the Python docstrings for more information.
How to review
Unit tests cover every validation rule extensively and provide a good understanding of what rules exist and how each one is enforced (
test_validate_chlog_file_rules
test method is a good start). Also, feel free to checkout the branch and run the script in your local copy of the Uyuni repository.Documentation
--help
command)Test coverage
pytest
)Links
Fixes https://github.com/SUSE/spacewalk/issues/2734
Changelogs
Make sure the changelogs entries you are adding are compliant with https://github.com/uyuni-project/uyuni/wiki/Contributing#changelogs and https://github.com/uyuni-project/uyuni/wiki/Contributing#uyuni-projectuyuni-repository
If you don't need a changelog check, please mark this checkbox:
If you uncheck the checkbox after the PR is created, you will need to re-run
changelog_test
(see below)Re-run a test
If you need to re-run a test, please mark the related checkbox, it will be unchecked automatically once it has re-run: