One more thing: As I heard patchtest is basically dead at the moment. If I pick up on it I’ll first add documentation and fix all PEP8 violations, and add some CI to run (at least) flake8 and pytest. I’ll also add type hints as all that avoids errors and allows the next one to pick up the project with greater confidence. I’ll also add unit tests.
All that will lead to pretty large change sets. Do I need to send everything one by one as patches and wait for reviews or can I work on my clone https://github.com/HerrMuellerluedenscheid/patchtest <https://github.com/HerrMuellerluedenscheid/patchtest> and open a merge request somewhere? Best Marius > On 16. Apr 2022, at 13:28, Marius Kriegerowski via lists.openembedded.org > <[email protected]> wrote: > > 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] >> <mailto:[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 (#1520): https://lists.openembedded.org/g/openembedded-architecture/message/1520 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]] -=-=-=-=-=-=-=-=-=-=-=-
