Ok, one final thing for now... Speaking of CI: is there a framework that integrates into the current architecture? Do you run a self-hosted Jenkins, drone-ci, or alike somewhere that I can make use of?
Happy easter :) > On 16. Apr 2022, at 13:38, Marius Kriegerowski via lists.openembedded.org > <[email protected]> wrote: > > 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 >> <http://lists.openembedded.org/> >> <[email protected] >> <mailto:[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 (#1521): https://lists.openembedded.org/g/openembedded-architecture/message/1521 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]] -=-=-=-=-=-=-=-=-=-=-=-
