Hello everyone, After some time I found the time and took a deeper dive into patchtest. It’s not in the prettiest state and has a couple of design choices which make me wonder if it wouldn’t be better to go for a complete rewrite. e.g. I would rather opt for pytest as it’s much more lightweight and easier to work with and more modern than unittest. But let me dive deeper first.
Patchtest is hardly documented which makes it hard to follow. Or is there any more documentation out there outside of the repo? I would start writing documentation but want to make sure that I don’t repeat what others have done before. There are selftests but they don’t work: https://github.com/HerrMuellerluedenscheid/patchtest/tree/overhaul/selftest <https://github.com/HerrMuellerluedenscheid/patchtest/tree/overhaul/selftest> Can these be removed? I’m assuming that in the CI context the `--json` flag is used to produce json output which is then somehow parsed and returned to the user, right? I would like to work with the DevOps integration team to make sure I’m not deviating too far from what the integration team expects. I managed to make it run on my machine but even if one test fails, it returns OK in the end. Was that implemented on purpose to make this work in the CI context? So, just for me to know if I’m on the right track, does this look like a reasonable output indicating that it works fine? ❯ patchtest ../poky/0001-scriptutils-fix-style-to-be-more-PEP8-compliant.patch ../poky ../patchtest-oe/tests Testing patch ../poky/0001-scriptutils-fix-style-to-be-more-PEP8-compliant.patch run pre-merge tests BUILDDIR is not defined. Cannot load bitbake SKIP setUpClass (test_metadata_lic_files_chksum.LicFilesChkSum) BUILDDIR is not defined. Cannot load bitbake SKIP setUpClass (test_metadata_src_uri.SrcUri) SKIP test_python_pylint.PyLint.pretest_pylint ---------------------------------------------------------------------- Ran 1 test in 0.548s OK run post-merge tests PASS test_mbox_author.Author.test_author_valid PASS test_mbox_author.Author.test_non_auh_upgrade PASS test_mbox_bugzilla.Bugzilla.test_bugzilla_entry_format SKIP test_mbox_description.CommitMessage.test_commit_message_presence PASS test_mbox_format.MboxFormat.test_mbox_format PASS test_mbox_mailinglist.MailingList.test_target_mailing_list FAIL test_mbox_merge.Merge.test_series_merge_on_head PASS test_mbox_shortlog.Shortlog.test_shortlog_format PASS test_mbox_shortlog.Shortlog.test_shortlog_length FAIL test_mbox_signed_off_by.SignedOffBy.test_signed_off_by_presence BUILDDIR is not defined. Cannot load bitbake SKIP setUpClass (test_metadata_lic_files_chksum.LicFilesChkSum) BUILDDIR is not defined. Cannot load bitbake SKIP setUpClass (test_metadata_license.License) SKIP test_metadata_max_length.MaxLength.test_max_line_length BUILDDIR is not defined. Cannot load bitbake SKIP setUpClass (test_metadata_src_uri.SrcUri) BUILDDIR is not defined. Cannot load bitbake SKIP setUpClass (test_metadata_summary.Summary) SKIP test_patch_cve.CVE.test_cve_tag_format SKIP test_patch_signed_off_by.PatchSignedOffBy.test_signed_off_by_presence SKIP test_patch_upstream_status.PatchUpstreamStatus.test_upstream_status_presence_format SKIP test_python_pylint.PyLint.test_pylint ---------------------------------------------------------------------- Ran 15 tests in 0.260s OK Looking forward bringing this up to speed again. Marius > On 18. Feb 2022, at 22:41, Konrad Weihmann <[email protected]> wrote: > > Yep, that is what the discussion was about - in my opinion every path should > treated equally, which is somehow blocked by the very unique way this project > tends to validate patches. > So either the project is opening up to contributions from different workflows > or we all have to fold our hands and pray that someone is eager to reactivate > patchtest :-) > > BTW I think patchtest might be the compromise we are all looking for, but as > of now I see no incentive for everyone out of OE scope to pick up the pieces > that are there. > Concluding from that the options are > - have patchtest being picked up by someone willing to maintain that in the > long run > - completely drop the idea of integrating any kind of linter as of now > > I don't want to offend anyone - but a clear yes/no decision would be helpful > - just begging for someone to pick the pieces of patchtest isn't going to > really help > > > On 18.02.22 22:18, Trevor Woerner wrote: >> I think Richard tried to allude to this in the github conversation, but I >> think it might have got lost. >> Currently, there is only one path for submitting a patch to oe-core: the >> mailing list. But for submitting patches to meta-openembedded there are now >> two acceptable paths: mailing list and github pull request. >> We have to make sure all paths are treated equally. >> If the linting is only applied to the github pull request path and not the >> mailing list path, then people submitting patches via github will be subject >> to more stringent rules than those who use the mailing list. >> Inevitably patches will get through via the mailing list that would have >> failed the linting process were they sent as github pull requests. The next >> person to submit a patch via github will be forced to fixup the linting of >> not >> only their work, but of the recent patches that came in through the mailing >> list and were not linted (and had linting issues). >> We should always try to make sure all proposed patches are treated the same. > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1519): https://lists.openembedded.org/g/openembedded-architecture/message/1519 Mute This Topic: https://lists.openembedded.org/mt/88763351/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
