உள்ளடக்கத்திற்கு செல்க

ஒரு புதிய அம்சத்தைச் செயல்படுத்துதல்

முன்மொழிவு செயல்முறை முடிந்தவுடன், ஒரு புதிய அம்சத்திற்கான முழுமையான வடிவமைப்பு உங்களிடம் இருக்க வேண்டும். அதாவது, எழுதத் தொடங்க வேண்டிய நேரம் இது!

உங்கள் அம்சத்திற்கு ஒரு தள-குறிப்பிட்ட செயலாக்கம் தேவைப்பட்டால், அந்த யோசனை அனைத்துத் தளங்களிலும் செயல்படுத்தப்பட முடியும் என்பதை முன்மொழிவு செயல்முறை சரிபார்த்திருக்க வேண்டும். இருப்பினும், ஒரு புதிய அம்சத்தை முதன்முதலில் செயல்படுத்தும் நபராக, அனைத்துத் தளங்களுக்கும் அந்த புதிய அம்சத்தைச் செயல்படுத்துவதற்கு நீங்கள் பொறுப்பல்ல. சோதனைகள் உட்பட, குறைந்தபட்சம் ஒரு தளத்திற்கு நீங்கள் ஒரு முழுமையான செயலாக்கத்தை வழங்க வேண்டும். மற்ற தளங்களுக்கு, நீங்கள் ஒரு "ஸ்டப்" செயலாக்கத்தை வழங்க வேண்டும் - இது வெறும் இடைமுக வரையறையை மட்டும் வழங்கி, அந்தத் தளத்தில் செயல்பாடு செயல்படுத்தப்படவில்லை என்பதைக் குறிக்கும் வகையில் ஒரு NotImplementedError பிழையை அல்லது ஒரு பதிவுச் செய்தியை வெளியிடும் ஒரு செயலாக்கமாகும்.

ஒரு புதிய அம்சத்தைச் செயல்படுத்துவதில் ஒரு முக்கிய பகுதி, அந்த அம்சம் முழுமையாக ஆவணப்படுத்தப்பட்டுள்ளதா என்பதை உறுதி செய்வதாகும். குறைந்தபட்சம், இது API ஆவணங்கள் இருப்பதை உறுதி செய்வதாகும்; ஆனால் இது ஒரு செய்முறை வழிகாட்டி அல்லது தலைப்பு வழிகாட்டியைச் சேர்ப்பதையும் தேவைப்படலாம்.

புதிய செயல்பாட்டைச் சேர்த்தல்

ஒரு மேம்பாட்டுச் சூழலை அமைக்கவும்

ஒரு மேம்பாட்டுச் சூழலை அமைத்தல்

நீங்கள் பங்களிக்கும் திட்டத்தைப் பொறுத்து, ஒரு மேம்பாட்டுச் சூழலை அமைப்பதற்கான படிகள் மாறுபடும். பின்வருவனவற்றிலிருந்து தேர்ந்தெடுக்கவும்:

நீங்கள் பங்களிக்க விரும்பும் களஞ்சியம் இந்தப் பட்டியலில் இல்லை என்றால், மிகவும் பொருத்தமான திட்டத்திற்கான மேம்பாட்டு வழிகாட்டியைப் பின்பற்றவும். உதாரணமாக, நீங்கள் ஒரு பிரீஃப்கேஸ் வார்ப்புரு களஞ்சியத்தில் பணியாற்ற விரும்பினால், நீங்கள் பிரீஃப்கேஸிற்கான வழிகாட்டியைப் பின்பற்ற வேண்டும்.

கிளையிலிருந்து வேலை செய்யுங்கள்

உங்கள் main கிளை அல்ல, ஒரு அம்சக் கிளையிலிருந்து வேலை செய்யுங்கள்.

உங்கள் மாற்றத்தில் வேலை செய்யத் தொடங்குவதற்கு முன், நீங்கள் ஒரு கிளை உருவாக்கியுள்ளீர்கள் என்பதை உறுதிப்படுத்திக் கொள்ளுங்கள். இயல்பாக, உங்கள் களஞ்சியப் பிளக்கை நீங்கள் நகலெடுக்கும்போது, உங்கள் main கிளையில் நீங்கள் சரிபார்க்கப்படுவீர்கள். இது BeeWare-இன் main கிளையின் நேரடி நகலாகும்.

உங்கள் main கிளைகளிலிருந்து ஒரு புல் கோரிக்கையைச் சமர்ப்பிக்க முடிந்தாலும், நீங்கள் அவ்வாறு செய்யாமல் இருப்பது நல்லது. நீங்கள் கிட்டத்தட்ட சரியான ஒரு புல் கோரிக்கையைச் சமர்ப்பித்தால், உங்கள் புல் கோரிக்கையை மதிப்பாய்வு செய்யும் முக்கியக் குழு உறுப்பினர், ஒரு சிறிய மாற்றத்தைக் கேட்கும் கருத்துக்களைக் கொடுப்பதற்குப் பதிலாக, தேவையான மாற்றங்களைச் செய்ய முடியும். இருப்பினும், உங்கள் main கிளை இருந்து உங்கள் புல் கோரிக்கையைச் சமர்ப்பித்தால், மதிப்பாய்வாளர்கள் மாற்றங்களைச் செய்வதிலிருந்து தடுக்கப்படுகிறார்கள்.

உங்கள் முதன்மை கிளை (main branch) அடிப்படையிலான உங்கள் முதல் புல் கோரிக்கையை முடித்த பிறகு, அதிலிருந்து வேலை செய்வது உங்களுக்கும் கடினமாக்குகிறது. நீங்கள் இரண்டாவது புல் ரிக்வெஸ்டில் வேலை செய்ய விரும்பினால், உங்கள் இரண்டாவது பங்களிப்பை அடிப்படையாகக் கொள்ள, அப்ஸ்ட்ரீம் திட்டத்தின் பிரதான கிளைக்கான ஒரு "தூய்மையான" பிரதியை நீங்கள் வைத்திருக்க வேண்டும்; உங்கள் முதல் பங்களிப்பை உங்கள் main கிளையிலிருந்து செய்திருந்தால், அந்தத் தூய்மையான பதிப்பு இனி உங்களிடம் இருக்காது.

அதற்குப் பதிலாக, நீங்கள் உங்கள் மாற்றங்களை ஒரு ஃபீச்சர் பிராஞ்சில் செய்ய வேண்டும். நீங்கள் செய்த மாற்றத்தை அடையாளம் காண, ஒரு ஃபீச்சர் பிராஞ்ச் ஒரு எளிய பெயரைக் கொண்டிருக்கும். உதாரணமாக, நீங்கள் விண்டோஸ் 11-ல் கட்டமைப்புப் பிரச்சினைகளை ஏற்படுத்தும் ஒரு பிழையைச் சரிசெய்கிறீர்கள் என்றால், நீங்கள் ஒரு அம்சக் கிளையை fix-win11-build என உருவாக்கலாம். உங்கள் பிழை, ஏற்கனவே புகாரளிக்கப்பட்ட ஒரு குறிப்பிட்ட சிக்கலுடன் தொடர்புடையது என்றால், கிளைப் பெயரில் அந்தச் சிக்கல் எண்ணைக் குறிப்பிடுவதும் வழக்கம் (எ.கா., fix-1234).

ஒரு fix-win11-build ஃபீச்சர் பிராஞ்சை உருவாக்க, ஓட்டுங்கள்:

(.venv) $ git switch -c fix-win11-build

(.venv) $ git switch -c fix-win11-build

(.venv) C:\...>git switch -c fix-win11-build
எல்லை மீறலைத் தவிர்க்கவும்

எல்லை மீறலைத் தவிர்த்தல்

"எல்லை மீறல்" என்பது, ஒரு தனிப்பட்ட பங்களிப்பால் சரிசெய்யப்பட்ட சிக்கல்கள் அல்லது செயல்படுத்தப்பட்ட அம்சங்களின் பட்டியல், வேலை தொடங்கியபோது நோக்கமாக இருந்தது என்பதை விட கணிசமாக அதிகமாக வளரும்போது நிகழ்கிறது. நீங்கள் ஒரு எளிய சிக்கலுடன் தொடங்குகிறீர்கள்; அதனுடன் நெருங்கிய தொடர்புடைய மற்றொரு சிக்கலைக் கண்டறிந்து, அந்தத் தீர்வையும் சேர்க்க முடிவு செய்கிறீர்கள்; பின்னர் மூன்றாவது… நீங்கள் உணர்வதற்குள், டஜன் கணக்கான கோப்புகளை உள்ளடக்கி, 5 சிக்கல்களைத் தீர்த்து 3 புதிய அம்சங்களைச் சேர்க்கும் ஒரு புல் கோரிக்கையை நீங்கள் பெற்றிருப்பீர்கள்.

திட்ட வரம்பு மீறல் அனைவருக்கும் நடப்பதுண்டு. இது அனுபவமிக்க டெவலப்பர்களுக்கு நன்கு தெரிந்த ஒரு கருத்தாகும்; நாம் அனைவரும் பலமுறை இதைச் செய்திருக்கிறோம், அதனால் ஏற்படும் அனைத்துப் பிரச்சனைகளையும் அனுபவித்திருக்கிறோம்.

வளர்ச்சி எல்லை மீறலைத் தவிர்ப்பதற்கு மிகவும் நடைமுறைக்குரிய காரணங்கள் உள்ளன. ஒரு பங்களிப்பு எவ்வளவு பெரியதாகிறதோ, அதைக் கையாள்வது அவ்வளவு கடினமாகிறது. விளிம்புநிலை நிகழ்வுகள் அல்லது சாத்தியமான சிக்கல்களைக் கண்டறிவது கடினமாகிவிடும், இதன் பொருள் அந்தப் பங்களிப்பின் ஒட்டுமொத்தத் தரம் குறையக்கூடும். மதிப்பாய்வாளர் ஒன்றுக்கு மேற்பட்ட, தொடர்பில்லாத சூழல்களைக் கையாள வேண்டியிருக்கும்போது, மதிப்பாய்வுகளும் மிகவும் சவாலானதாகின்றன. ஒரு பெரிய பங்களிப்பு என்பது அதிக மதிப்பாய்வுக் கருத்துக்களைக் குறிக்கும், மேலும் ஒரு பங்களிப்பாளராக, பல மதிப்பாய்வுத் திரிகளைப் பின்தொடர்வது கடினமாகிவிடும். உங்கள் GitHub அனுபவமும் பாதிக்கப்படும் - ஒரு PR-இன் அளவு அதிகரிக்கும்போது GitHub-இன் பயனர் இடைமுகம் (UI) மெதுவாகிவிடும், அதாவது GitHub இடைமுகம் மூலம் கோப்புகளைப் பார்ப்பதும், மதிப்பாய்வுக் கருத்துக்களை இடுவதும் மிகவும் கடினமாகிவிடும்.

அசல் முன்மொழிவு அல்லது பிழை அறிக்கையின் வெளிப்படையான பகுதியாக இல்லாத எதையும் உங்கள் பங்களிப்பில் சேர்க்க ஒரு காரணத்தைக் கண்டறியும் போதெல்லாம், நீங்கள் வரம்பு மீறலை நோக்கிச் செல்கிறீர்களா என்பதைக் கருத்தில் கொள்ள வேண்டும். தனித்தனியாகச் செயல்படுத்தக்கூடிய இரண்டு வெவ்வேறு அம்சங்கள் உள்ளனவா? ஒரு அம்சத்தை அறியப்பட்ட வரம்பு அல்லது பிழையுடன் செயல்படுத்தி, அந்தப் பிழையை ஒரு பின்தொடர் புல் ரிக்வெஸ்டில் சரிசெய்ய முடியுமா? ஒரு பிழைச் சரிசெய்தலின் ஒரு பகுதி மற்றொன்றிலிருந்து தன்னிச்சையாக உள்ளதா? ஒரு மாற்றத்தின் ஒரு பகுதியை அசல் பங்களிப்பை மாற்றாமல் தவிர்க்க முடிந்தால், அது அநேகமாக தவிர்க்கப்பட வேண்டும்.

மென்பொருளை உருவாக்குவது என்பது எப்போதும் படிப்படியான முன்னேற்றத்தின் ஒரு செயல்முறையாகும். ஒவ்வொரு தனிப்பட்ட பங்களிப்பும் இணைக்கப்படும்போது குறியீட்டுத் தொகுப்பை ஒரு சிறந்த நிலையில் விட்டுச் செல்ல வேண்டும், ஆனால் பிழைகள் அல்லது அம்சங்களின் பகுதிகளை எதிர்கால மேம்பாட்டிற்கான பணியாக விட்டுச் செல்வது முற்றிலும் ஏற்றுக்கொள்ளத்தக்கது. இதன் பொருள், ஒரு இழுப்புக் கோரிக்கையை (pull request) தன்னிச்சையாக மதிப்பாய்வு செய்யக்கூடிய பல பகுதிகளாகப் பிரித்தல், அல்லது வேறு யாராவது சிக்கலை ஆராய்ந்து தீர்க்கும் வகையில் ஒரு சிக்கலைப் பதிவு செய்தல் ஆகியவையாக இருக்கலாம்.

ஒவ்வொரு பங்களிப்பின் வரம்பைக் கட்டுப்படுத்துவது, உங்களை உள்ளடக்கி சம்பந்தப்பட்ட அனைவருக்கும் உதவுகிறது. உங்கள் மதிப்பாய்வாளர்கள், ஏன் நீங்களும் கூட, இதைப் பாராட்டுவார்கள்.

புதிய அம்சத்தைச் செயல்படுத்தவும்

எழுதுதல், இயக்கிப் பார்த்தல் மற்றும் சோதனை செய்தல்

ஒரு பிழையைச் சரிசெய்வதற்கோ அல்லது ஒரு அம்சத்தைச் செயல்படுத்துவதற்கோ நீங்கள் சில புதிய குறியீட்டை எழுத வேண்டியிருக்கும்.

கோடில் வேலை செய்யத் தொடங்க, நீங்கள் ஒரு வளர்ச்சிச் சூழலை அமைத்துள்ளீர்கள் என்பதையும், ஒரு கிளையில் வேலை செய்கிறீர்கள் என்பதையும் உறுதிப்படுத்திக் கொள்ளுங்கள்.

BeeWare-க்கான குறியீட்டை எழுதுவதற்கான எங்கள் வழிகாட்டுதல்களை விவரிக்கும் ஒரு குறியீட்டு நடை வழிகாட்டி எங்களிடம் உள்ளது.

சோதனை வழி மேம்பாடு

உங்கள் குறியீடு நீங்கள் எதிர்பார்ப்பதைச் செய்யும் என்பதை உறுதி செய்வதற்கான ஒரு நல்ல வழி, முதலில் அதைச் சோதிக்க ஒரு சோதனை நிகழ்வை எழுதுவதாகும். இந்தச் சோதனை நிகழ்வு ஆரம்பத்தில் தோல்வியடைய வேண்டும், ஏனெனில் அது சோதிக்கும் குறியீடு இன்னும் உருவாக்கப்படவில்லை. பின்னர், சோதனையில் வெற்றிபெறத் தேவையான குறியீடு மாற்றங்களை நீங்கள் எழுதலாம், மேலும் நீங்கள் எழுதியது நீங்கள் எதிர்பார்க்கும் சிக்கலைத் தீர்க்கிறது என்பதை அறிந்து கொள்ளலாம்.

உங்கள் குறியீட்டை இயக்கவும்

உங்கள் குறியீடு எழுதப்பட்டவுடன், அது இயங்குகிறதா என்பதை நீங்கள் உறுதி செய்ய வேண்டும். நீங்கள் எதிர்பார்ப்பதை அது செய்கிறதா என்பதைச் சரிபார்க்க, உங்கள் குறியீட்டை நீங்கள் கைமுறையாக இயக்க வேண்டும். நீங்கள் இன்னும் செய்யவில்லை என்றால், உங்கள் மாற்றங்களுக்காக ஒரு சோதனை நிகழ்வை எழுத வேண்டும்; மேலே குறிப்பிட்டது போல், உங்கள் குறியீடு கருத்துரைக்கப்பட்டிருந்தாலோ அல்லது இல்லை என்றாலோ இந்தச் சோதனை தோல்வியடைய வேண்டும்.

உங்கள் சோதனை நிகழ்வை மற்ற சோதனைகளுடன் சேர்த்து இயக்கக்கூடிய வகையில் சோதனைத் தொகுப்பில் சேர்ப்பீர்கள். அடுத்த கட்டம், சோதனைத் தொகுப்பை இயக்குவதாகும்.

சோதனைகளை இயக்குதல் மற்றும் கவரேஜ்

BeeWare சோதனை செயல்முறையை நிர்வகிக்க tox மற்றும் அதன் சொந்த சோதனைத் தொகுப்பிற்கு pytest ஐப் பயன்படுத்துகிறது.

பூர்வீக tox கட்டளை இயங்குவதை உள்ளடக்கியது:

  • முன்-அர்ப்பணிப்பு கொக்கிகள்
  • towncrier வெளியீட்டுக் குறிப்பு சரிபார்ப்பு

  • ஆவணப்படுத்தல் லிண்டிங்

  • கிடைக்கும் பைத்தான் பதிப்புகளுக்கான சோதனைத் தொகுப்பு

  • குறியீட்டு உள்ளடக்க அறிக்கை

நீங்கள் ஒரு புல் ரிக்குவஸ்ட்டை சமர்ப்பிக்கும்போது, அடிப்படையில் CI இதுதான் இயக்கும்.

முழுமையான சோதனைத் தொகுப்பை இயக்க, இயக்கி:

(.venv) $ tox

(.venv) $ tox

(.venv) C:\...>tox

முழுமையான சோதனைத் தொகுப்பை இயக்க சிறிது நேரம் ஆகலாம். tox ஐ இணையாக இயக்குவதன் மூலமும், tox p (அல்லது tox run-parallel)-ஐ இயக்குவதன் மூலமும் நீங்கள் இதை கணிசமாக வேகப்படுத்தலாம். சோதனைத் தொகுப்பை இணையாக இயக்கும்போது, அது இயங்கும் போது அதன் முன்னேற்றம் குறித்த குறைந்த பின்னூட்டத்தையே பெறுவீர்கள், ஆனால் சோதனை இயக்கம் முடிந்ததும் கண்டறியப்பட்ட ஏதேனும் சிக்கல்களின் சுருக்கத்தை நீங்கள் பெறுவீர்கள். சோதனைகள் நடத்தப்பட்டன என்பதைக் குறிக்கும் சில வெளியீட்டை நீங்கள் பெற வேண்டும். நீங்கள் SKIPPED சோதனைகளைக் காணலாம், ஆனால் FAIL அல்லது ERROR சோதனை முடிவுகளை ஒருபோதும் பெறக்கூடாது. ஒவ்வொரு பேட்சையும் இணைப்பதற்கு முன்பு நாங்கள் எங்கள் முழுமையான சோதனைத் தொகுப்பை இயக்குகிறோம். அந்தச் செயல்முறை ஏதேனும் சிக்கல்களைக் கண்டறிந்தால், நாங்கள் அந்தப் பேட்சை இணைப்பதில்லை. நீங்கள் ஒரு சோதனைப் பிழை அல்லது தோல்வியைக் கண்டறிந்தால், ஒன்று உங்கள் சோதனைச் சூழலில் ஏதேனும் விசித்திரமாக உள்ளது, அல்லது நாங்கள் இதற்கு முன்பு காணாத ஒரு விளிம்புநிலை நிகழ்வை நீங்கள் கண்டறிந்துள்ளீர்கள் - எதுவாக இருந்தாலும், எங்களுக்குத் தெரியப்படுத்துங்கள்!

சோதனைகள் தேர்ச்சி பெறுவதோடு கூடுதலாக, இது 100% சோதனை உள்ளடக்கம் எனவும் அறிக்கையிட வேண்டும்.

சோதனை மாறுபாடுகளை இயக்குதல்

பைத்தனின் பல பதிப்புகளுக்கு சோதனைகளை இயக்கவும்

வழக்கமாக, பல tox கட்டளைகள், BeeWare ஆதரிக்கும் ஒவ்வொரு Python பதிப்பிற்கும் ஒருமுறை என, சோதனைத் தொகுப்பை பலமுறை இயக்க முயற்சிக்கும். இருப்பினும், இதைச் செய்ய, ஒவ்வொரு Python பதிப்பும் உங்கள் கணினியில் நிறுவப்பட்டிருக்க வேண்டும் மற்றும் tox-இன் Python கண்டறிதல் செயல்முறைக்குக் கிடைக்கக்கூடியதாக இருக்க வேண்டும். பொதுவாக, ஒரு பைத்தான் பதிப்பு PATH வழியாகக் கிடைத்தால், tox அதைக் கண்டறிந்து பயன்படுத்த முடியும்.

சோதனைத் தொகுப்பை மட்டும் இயக்கவும்

நீங்கள் ஒரு புதிய அம்சத்தை வேகமாக மேம்படுத்திக் கொண்டிருந்தால், முழுமையான சோதனைத் தொகுப்பை இயக்க வேண்டிய அவசியமில்லை; நீங்கள் மட்டுமே யூனிட் சோதனைகளை இயக்கலாம். இதைச் செய்ய, பின்வருவனவற்றை இயக்கவும்:

(.venv) $ tox -e py

(.venv) $ tox -e py

(.venv) C:\...>tox -e py

சோதனைகளின் ஒரு பகுதியை நடத்துக

பயன்பாட்டுக்கு, tox யூனிட் டெஸ்ட் தொகுப்பில் உள்ள அனைத்து சோதனைகளையும் இயக்கும். நீங்கள் உங்கள் புதிய சோதனையை உருவாக்கும்போது, அந்த ஒரு சோதனையை மட்டும் இயக்குவது உதவியாக இருக்கும். இதைச் செய்ய, நீங்கள் pytest-க்கு ஒரு வாதமாக [எந்தவொரு (https://docs.pytest.org/en/latest/how-to/usage.html#specifying-which-tests-to-run) குறிப்பிடுவதையும்]tox அனுப்பலாம். இந்த சோதனைப் பாதைகள் briefcase கோப்பகத்திற்கு சார்புடையவை. உதாரணமாக, ஒரே கோப்பில் உள்ள சோதனைகளை மட்டும் இயக்க, பின்வருமாறு இயக்கவும்:

(.venv) $ tox -e py -- tests/path_to_test_file/test_some_test.py

(.venv) $ tox -e py -- tests/path_to_test_file/test_some_test.py

(.venv) C:\...>tox -e py -- tests/path_to_test_file/test_some_test.py

சோதனைத் தொகுப்பின் ஒரு பகுதியை இயக்கும்போதும் உங்களுக்கு ஒரு கவரேஜ் அறிக்கை கிடைக்கும் - ஆனால், நீங்கள் இயக்கிய குறிப்பிட்ட சோதனைகளால் செயல்படுத்தப்பட்ட கோட் வரிகளை மட்டுமே கவரேஜ் முடிவுகள் தெரிவிக்கும்.

ஒரு குறிப்பிட்ட பைத்தான் பதிப்பிற்கான சோதனைத் தொகுப்பை இயக்கவும்

பின்னமைப்பாக tox -e py உங்கள் கணினியில் python எனத் தீர்க்கப்படும் எந்தவொரு விளக்கிகொண்டும் இயங்கும். உங்களிடம் பல பைத்தான் பதிப்புகள் நிறுவப்பட்டிருந்தால், மேலும் நீங்கள் நிறுவியுள்ள பதிப்புகளில் இருந்து ஒரு குறிப்பிட்ட பைத்தான் பதிப்பைச் சோதிக்க விரும்பினால், பயன்படுத்த ஒரு குறிப்பிட்ட பைத்தான் பதிப்பை நீங்கள் குறிப்பிடலாம். உதாரணமாக, பைத்தான் 3.10 இல் சோதனைத் தொகுப்பை இயக்க, பின்வருவனவற்றை இயக்கவும்:

(.venv) $ tox -e py310

(.venv) $ tox -e py310

(.venv) C:\...>tox -e py310

கட்டளை வரியில் -- மற்றும் ஒரு சோதனை விவரக்குறிப்பைச் சேர்ப்பதன் மூலம் ஒரு சோதனைகளின் துணைக்குழு-ஐ இயக்க முடியும்.

கவரேஜ் இல்லாமல் சோதனைத் தொகுப்பை இயக்கவும் (வேகமாக)

இயல்பாக, tox pytest தொகுப்பை ஒற்றை இழை பயன்முறையில் (single threaded mode) இயக்கும். சோதனைத் தொகுப்பை இணை இழை பயன்முறையில் (parallel) இயற்றுவதன் மூலம் அதன் செயல்பாட்டை நீங்கள் வேகப்படுத்தலாம். உருவாக்கப்பட்ட செயல்முறைகளுக்குள் உள்ளடக்கத்தை (coverage) பதிவு செய்வதில் உள்ள சிக்கல்களால், இந்த பயன்முறை உள்ளடக்கக் கோப்புகளை (coverage files) உருவாக்காது. ஒரு தனி பைத்தான் பதிப்பை "வேகமான" பயன்முறையில் (fast mode) இயக்க, பின்வருமாறு இயற்றவும்:

(.venv) $ tox -e py-fast

(.venv) $ tox -e py-fast

(.venv) C:\...>tox -e py-fast

ஒரு சோதனைகளின் உட்பிரிவு-ஐ கட்டளை வரியில் -- மற்றும் ஒரு சோதனை விவரக்குறிப்பைச் சேர்ப்பதன் மூலம் இயக்கலாம்; ஒரு குறிப்பிட்ட பைத்தான் பதிப்பு-ஐ சோதனை இலக்கில் பதிப்பைச் சேர்ப்பதன் மூலம் பயன்படுத்தலாம் (எ.கா., பைத்தானில் py310-fast வேகமாக இயக்க 3.10).

குறியீடு உள்ளடக்கம்

BeeWare அதன் குறியீட்டுத் தொகுப்பில் 100% கிளை உள்ளடக்கத்தை பராமரிக்கிறது. நீங்கள் திட்டத்தில் குறியீட்டைச் சேர்க்கும்போது அல்லது மாற்றியமைக்கும்போது, நீங்கள் செய்யும் மாற்றங்களின் உள்ளடக்கத்தை உறுதிசெய்ய, சோதனைக் குறியீட்டைச் சேர்க்க வேண்டும்.

இருப்பினும், BeeWare பல தளங்களையும், பைத்தனின் பல பதிப்புகளையும் இலக்காகக் கொண்டுள்ளது, எனவே முழுமையான உள்ளடக்கத்தை ஒரே தளம் மற்றும் பைத்தான் பதிப்பில் சரிபார்க்க முடியாது. இதைச் சமாளிக்க, tool.coverage.coverage_conditional_plugin.rules பிரிவில் பல நிபந்தனை மறைப்பு விதிகள் வரையறுக்கப்பட்டுள்ளன (எ.கா., விண்டோஸில் சோதனைத் தொகுப்பை இயக்கும்போது செயல்படுத்தப்படாத ஒரு குறியீட்டுத் தொகுப்பைக் குறிக்க pyproject.toml பயன்படுத்தப்படலாம்). இந்த விதிகள், குறிப்பிட்ட தளங்கள் அல்லது பைத்தானின் பதிப்புகளில் மட்டுமே மறைக்கப்படும் குறியீட்டுப் பகுதிகளை அடையாளம் காணப் பயன்படுகின்றன.

குறிப்பிடத்தக்க வகையில், பைத்தான் பதிப்புகளுக்கு இடையே கவரேஜ் அறிக்கை செய்வது சற்று விசித்திரமாக இருக்கலாம். உதாரணமாக, கவரேஜ் கோப்புகள் ஒரு பைத்தான் பதிப்பைப் பயன்படுத்தி உருவாக்கப்பட்டு, ஆனால் மற்றொரு பதிப்பில் கவரேஜ் அறிக்கை செய்யப்பட்டால், தவறவிட்ட கிளைகளுக்கான தவறான நேர்மறை முடிவுகள் அந்த அறிக்கையில் இருக்கலாம். இந்தக் காரணத்திற்காக, கவரேஜ் கோப்புகளை உருவாக்கப் பயன்படுத்தப்பட்ட பைத்தானின் பழமையான பதிப்பையே கவரேஜ் அறிக்கை எப்போதும் பயன்படுத்த வேண்டும்.

கவரேஜ் முடிவுகளைப் புரிந்துகொள்ளுதல்

கவரேஜ் சோதனை வெளியீட்டின் முடிவில், சேகரிக்கப்பட்ட கவரேஜ் தரவுகளின் அறிக்கை இருக்க வேண்டும்:

பெயர்    கூற்றுகள்   தவறுகள்   கிளை   பகுதி   உறை   விடுபட்டவை
 ---------------------------------------------------
 மொத்தம்    7540 0   1040 0  100.0%

சோதனைத் தொகுப்பு குறியீட்டில் உள்ள ஒவ்வொரு சாத்தியமான கிளைப் பாதையையும் இயக்கியுள்ளது என்பதை இது நமக்குத் தெரிவிக்கிறது. இது பிழைகள் இல்லை என்பதற்கு 100% உத்தரவாதம் அளிக்கவில்லை, ஆனால் குறியீட்டுத் தொகுப்பில் உள்ள ஒவ்வொரு வரியையும் நாம் இயக்கிப் பார்க்கிறோம் என்று இது அர்த்தப்படுத்துகிறது.

நீங்கள் குறியீட்டுத் தொகுப்பில் மாற்றங்களைச் செய்தால், இந்த உள்ளடக்கத்தில் ஒரு இடைவெளியை நீங்கள் அறிமுகப்படுத்தக்கூடும். இது நிகழும்போது, எந்த வரிகள் இயக்கப்படவில்லை என்பதை உள்ளடக்க அறிக்கை உங்களுக்குக் கூறும். உதாரணமாக, நாம் some/interesting_file.py-இல் சில புதிய தர்க்கங்களைச் சேர்த்து ஒரு மாற்றத்தைச் செய்ததாகக் கொள்வோம். உள்ளடக்க அறிக்கை ஏறக்குறைய இவ்வாறு இருக்கலாம்:

பெயர் அறிக்கைகள்   செல்வி பிராஞ்ச் பகுதி   உறை   விடுபட்டது
 -------------------------------------------------------------------------------
 src/some/interesting_file.py 111 1     26 0  98.1%   170, 302-307, 320->335
 -------------------------------------------------------------------------------
 மொத்தம் 7540 1   1726 0  99.9%

சோதனைத் தொகுப்பால் வரி 170, வரிகள் 302-307, மற்றும் வரி 320-லிருந்து வரி 335-க்குச் செல்லும் ஒரு கிளை ஆகியவை செயல்படுத்தப்படவில்லை என்பதை இது நமக்குத் தெரிவிக்கிறது. இந்த உள்ளடக்கத்தை மீட்டெடுக்க நீங்கள் புதிய சோதனைகளைச் சேர்க்க வேண்டும் (அல்லது ஏற்கனவே உள்ள சோதனையைத் திருத்த வேண்டும்).

விருந்தளிக்கும் தளம் மற்றும் பைத்தான் பதிப்புக்கான உள்ளடக்க அறிக்கை

உங்கள் பிளாட்ஃபார்ம் மற்றும் பைத்தானின் பதிப்பிற்கான ஒரு கவரேஜ் அறிக்கையை நீங்கள் உருவாக்கலாம். உதாரணமாக, டெஸ்ட் சூட்டை இயக்கி, பைத்தான் 3.10 இல் ஒரு கவரேஜ் அறிக்கையை உருவாக்க, இயக்கும்:

(.venv) $ tox -m test310

(.venv) $ tox -m test310

(.venv) C:\...>tox -m test310

விருந்தளிக்கும் தளத்திற்கான உள்ளடக்க அறிக்கை

பைத்தனின் ஆதரிக்கப்படும் அனைத்துப் பதிப்புகளும் tox-க்குக் கிடைத்தால், ஹோஸ்ட் தளத்திற்கான கவரேஜை பின்வருவனவற்றை இயக்கி அறிக்கையிடலாம்:

(.venv) $ tox p -m test-platform

(.venv) $ tox p -m test-platform

(.venv) C:\...>tox p -m test-platform

HTML-ல் உள்ளடக்க அறிக்கை

கவரேஜ் -html சுற்றுச்சூழல் பெயர்களில் ஏதேனும் ஒன்றிற்கு tox என்பதைச் சேர்ப்பதன் மூலம் ஒரு HTML கவரேஜ் அறிக்கையை உருவாக்கலாம், உதாரணமாக:

(.venv) $ tox -e coverage-platform-html

(.venv) $ tox -e coverage-platform-html

(.venv) C:\...>tox -e coverage-platform-html

இது வெறும் தேர்வுகளை எழுதுவது மட்டுமல்ல!

எங்கள் எல்லா குறியீடுகளையும் சோதிப்பதை நாங்கள் உறுதி செய்தாலும், இந்தப் பணி என்பது அந்தச் சோதனை அளவைப் பராமரிப்பது மட்டும் அல்ல. இந்தப் பணியின் ஒரு பகுதி, நீங்கள் குறியீட்டை எழுதும்போதே அதைத் தணிக்கை செய்வதும் ஆகும். நீங்கள் ஒரு கான்கிரீட் உயிர் காப்பு vest-க்கு ஒரு விரிவான சோதனைத் தொகுப்பை எழுதலாம்… ஆனால் ஒரு கான்கிரீட் உயிர் காப்பு vest, அது உருவாக்கப்பட்ட நோக்கத்திற்காக இன்னும் பயனற்றதாகவே இருக்கும்!

நீங்கள் சோதனைகளை உருவாக்கும்போது, முக்கிய தொகுதி உட்புறமாக சீராக உள்ளதா என்பதையும் சரிபார்க்க வேண்டும். உள்ளகத்தில் சீரற்றதாக இருக்கும் ஏதேனும் மெத்தட் பெயர்களை நீங்கள் கவனித்தால் (எ.கா., ஒரு மாட்யூலில் on_select என்று அழைக்கப்படுவது, மற்றொன்றில் on_selected என்று அழைக்கப்படுவது), அல்லது தரவு சீராகக் கையாளப்படாத இடங்களைக் கண்டால், அதைக் குறிப்பிட்டு ஒரு டிக்கெட் எழுப்புவதன் மூலம் எங்கள் கவனத்திற்குக் கொண்டு வாருங்கள். அல்லது, என்ன செய்ய வேண்டும் என்பது உங்களுக்குத் தெரியும் என்பதில் நீங்கள் நம்பிக்கையுடன் இருந்தால், நீங்கள் கண்டறிந்த சிக்கலைச் சரிசெய்யும் ஒரு புல் கோரிக்கையை உருவாக்குங்கள்.

அனைத்தும் சரியாக வேலை செய்தவுடன், உங்கள் மாற்றங்களுடன் ஒரு புல் ரிக்குவஸ்டை சமர்ப்பிக்கலாம்.

ஆவணங்களை உருவாக்கு

கட்டுமான ஆவணங்கள்

BeeWare-இன் ஆவணத்தில் ஏதேனும் மாற்றங்களைச் செய்வதற்கு முன், ஏற்கனவே உள்ள ஆவணத்தை உங்களால் உருவாக்க முடியும் என்பதை உறுதி செய்வது உதவியாக இருக்கும்.

நீங்கள் ஆவணத்தை உருவாக்குவதற்கும், ஒரு மேம்பாட்டுச் சூழலை அமைப்பதற்கும் முன்.

உங்கள் path-இல் ஒரு Python 3.13 இன்டர்ப்ரெட்டர் நிறுவப்பட்டு, கிடைக்கப்பெற வேண்டும் (அதாவது, python3.13 ஒரு Python 3.13 இன்டர்ப்ரெட்டரைத் தொடங்க வேண்டும்).

BeeWare ஆவணங்களை உருவாக்க tox-ஐப் பயன்படுத்துகிறது. பின்வரும் tox கட்டளைகள், tox.ini கோப்பு உள்ள அதே இடத்திலிருந்து இயக்கப்பட வேண்டும், அது திட்டத்தின் ரூட் டைரக்டரியில் உள்ளது.

நேரடி ஆவண முன்னோட்டம்

ஆவணங்களை விரைவாகத் திருத்த உதவுவதற்காக, BeeWare ஒரு "நேரடி முன்னோட்டம்" பயன்முறையைக் கொண்டுள்ளது.

நேரடி முன்னோட்டம் எச்சரிக்கைகளுடன் உருவாக்கப்படும்!

உங்கள் ஆவணப் புதுப்பிப்புகளைச் சோதித்து மேம்படுத்த, நேரலை சேவை (live serve) கிடைக்கிறது. நீங்கள் புதுப்பிப்புகளைச் செய்யும் போது, ஒரு மார்க்அப் சிக்கலை ஏற்படுத்தக்கூடும். WARNING எனக் கருதப்படும் சிக்கல்கள் ஒரு சாதாரண பில்டைத் தோல்வியடையச் செய்யும், இருப்பினும், லைவ் சர்வ் பில்டிங்கைத் தொடரும் அதே வேளையில், கன்சோல் வெளியீட்டில் எச்சரிக்கைகளைக் காட்டும்படி அமைக்கப்பட்டுள்ளது. இது லைவ் ப்ரீவியூவை மீண்டும் தொடங்க வேண்டிய அவசியமின்றி, உங்கள் மாற்றங்களைத் திரும்பச் செய்ய அனுமதிக்கிறது.

ஒரு WARNING என்பது மற்றொரு ERROR-இலிருந்து வேறுபட்டது. நீங்கள் ERROR எனக் கருதப்படும் ஒரு சிக்கலை அறிமுகப்படுத்தினால், நேரலைச் சேவை தோல்வியடையும், மேலும் அதை மீண்டும் தொடங்க வேண்டும். WARNING சிக்கல் தீர்க்கப்படும் வரை அது மீண்டும் தொடங்காது.

நேரலை சேவையகத்தைத் தொடங்க:

(venv) $ tox -e docs-live

(venv) $ tox -e docs-live

(venv) C:\...>tox -e docs-live

இது ஆவணங்களை உருவாக்கி, ஆவணங்களை வழங்க ஒரு வலை சேவையகத்தைத் தொடங்கி, ஆவணங்களின் மூலக் கோப்புகளில் ஏதேனும் மாற்றங்கள் ஏற்படுகிறதா என கோப்பு அமைப்பைக் கண்காணிக்கும்.

சர்வர் துவக்கப்பட்டவுடன், கன்சோல் வெளியீட்டில் பின்வருவன போன்ற ஒன்றை நீங்கள் காண்பீர்கள்:

தகவல் - [11:18:51] http://127.0.0.1:8000/ இல் சேவை செய்கிறது

ஒரு உலாவியைத் திறந்து, வழங்கப்பட்ட URL-க்குச் செல்லவும். இப்போது நீங்கள் ஆவணத்தில் திருத்தங்களைச் செய்யத் தொடங்கலாம். ஒரு மாற்றம் கண்டறியப்பட்டால், ஆவணம் மீண்டும் உருவாக்கப்படும், மேலும் மாற்றியமைக்கப்பட்ட பக்கத்தைப் பார்க்கும் எந்தவொரு உலாவியும் தானாகவே புதுப்பிக்கப்படும்.

docs-live ஒரு ஆரம்பப் படியாகும்.

நேரலை சேவையகத்துடன் வேலை செய்ய docs-live இயக்குவது ஆரம்பகட்ட மறுஆய்வுக்கு மட்டுமே. ஒரு புல் கோரிக்கையைச் சமர்ப்பிக்கும் முன், நீங்கள் எப்போதும் ஒரு உள்ளூர் உருவாக்கத்தை இயக்க வேண்டும்.

உள்ளூர் உருவாக்கம்

நீங்கள் மீண்டும் மீண்டும் மேம்படுத்துவதை முடித்தவுடன், ஆவணங்களுக்கான உள்ளூர் கட்டமைப்பைச் செய்ய வேண்டும். ஏதேனும் குறியீட்டுப் பிழைகள் இருந்தால், இந்தக் கட்டமைப்புத் செயல்முறை தோல்வியடையும் வகையில் வடிவமைக்கப்பட்டுள்ளது. இது, நேரலை சேவையகத்தில் நீங்கள் தவறவிட்டிருக்கக்கூடிய எதையும் கண்டறிய உதவுகிறது.

உள்ளூர் உருவாக்கத்தை உருவாக்குதல்

உள்ளூர் பில்டை உருவாக்க:

(venv) $ tox -e docs

(venv) $ tox -e docs

(venv) C:\...>tox -e docs

இந்த பில்டின் வெளியீடு, ப்ராஜெக்ட்டின் ரூட் கோப்பகத்தில் உள்ள _build கோப்பகத்தில் இருக்கும்.

உள்ளூர் மொழிபெயர்க்கப்பட்ட பில்டை உருவாக்குதல்

BeeWareயின் ஆவணங்கள் பல மொழிகளில் மொழிபெயர்க்கப்பட்டுள்ளன. ஆங்கில ஆவணங்களில் செய்யப்படும் புதுப்பிப்புகள், மற்ற மொழி பில்ட்களில் சிக்கல்களை ஏற்படுத்தக்கூடும். ஒரு புல் கோரிக்கையைச் சமர்ப்பிக்கும் முன், அனைத்து பில்ட்களும் சரியாக வேலை செய்கின்றனவா என்பதைச் சரிபார்ப்பது அவசியம்.

கிடைக்கக்கூடிய அனைத்து மொழிபெயர்ப்புகளின் பில்டை உருவாக்க:

(வினைச்சொல்) $ tox -e docs-all

(வினைச்சொல்) $ tox -e docs-all

(venv) C:\...>tox -e docs-all

ஒவ்வொரு மொழி உருவாக்கத்தின் வெளியீடும் அதனுடன் தொடர்புடைய _build/html/<languagecode> கோப்பகத்தில் இருக்கும், இதில் <languagecode> என்பது அந்தந்த மொழியுடன் தொடர்புடைய இரண்டு அல்லது ஐந்து எழுத்துக்கள் கொண்ட மொழி குறியீடாகும் (எ.கா. பிரெஞ்சு மொழிக்கு fr, இத்தாலிய மொழிக்கு it, போன்றவை).

ஒரு தனிப்பட்ட பில்டில் உங்களுக்கு ஒரு சிக்கல் ஏற்பட்டால், tox -e docs-<languagecode> என்பதை இயக்கி அந்தந்த பில்டைத் தனித்தனியாக இயக்கலாம். உதாரணமாக, பிரெஞ்சு ஆவணங்களை மட்டும் உருவாக்க, பின்வருமாறு இயக்கவும்:

(venv) $ tox -e docs-fr

(venv) $ tox -e docs-fr

(venv) C:\...>tox -e docs-fr

ஒரு மொழிக்கான பில்டின் வெளியீடு _build கோப்பகத்தில் இருக்கும்.

ஆவணப்படுத்தல் லிண்டிங்

கட்டமைப்பு செயல்முறை மார்க்அப் பிழைகளைக் கண்டறியும், ஆனால் BeeWare என்பது "லிண்டிங்" எனப்படும் பாணி மற்றும் வடிவமைப்புக்கான சில கூடுதல் சோதனைகளைச் செய்கிறது. லிண்ட் சோதனைகளை இயக்க:

(venv) $ tox -e docs-lint

(venv) $ tox -e docs-lint

(venv) C:\...>tox -e docs-lint

இது ஆவணத்தில் பின்வருவன அடங்கவில்லை என்பதைச் சரிபார்க்கும்:

  • செயலிழந்த இணைப்புகள்
  • தவறாக எழுதப்பட்ட வார்த்தைகள்

ஒரு வார்த்தையின் சரியான எழுத்துப்பிழை, தவறாக எழுதப்பட்டதாகக் கண்டறியப்பட்டால், அந்த வார்த்தையை docs/spelling_wordlist என்பதில் உள்ள பட்டியலில் சேர்க்கவும். இது அந்த வார்த்தையை எழுத்துப்பிழை சரிபார்ப்பாளரின் அகராதியில் சேர்க்கும். இந்தப் பட்டியலில் சேர்க்கும்போது, நினைவில் கொள்ளுங்கள்:

  • நாங்கள் அமெரிக்க எழுத்துப்பிடியை விரும்புகிறோம், மேலும் நிரலாக்கத்திற்கே உரிய சில பேச்சு வழக்குகளுக்கும் (எ.கா., "apps") பெயர்களைச் செயலாக்குவதற்கும் (எ.கா., "scrollable") சில சுதந்திரங்கள் எடுத்துக்கொள்கிறோம்.
  • ஒரு தயாரிப்புப் பெயரைக் குறிப்பிடும்போது, அந்தத் தயாரிப்பின் விரும்பப்படும் பெரியெழுத்துப் பயன்பாட்டைப் பயன்படுத்த வேண்டும். (எ.கா., "macOS", "GTK", "pytest", "Pygame", "PyScript").
  • ஒரு சொல் "குறியீடாக" பயன்படுத்தப்பட்டால், அதை அகராதியில் சேர்ப்பதற்குப் பதிலாக, ஒரு நேரியல் (like this) ஆக மேற்கோள் காட்ட வேண்டும்.

நீங்கள் ஆவணங்களை வெற்றிகரமாக உருவாக்கியவுடன், ஆவணங்களை எழுத நீங்கள் தயாராக உள்ளீர்கள்.

ஆவணங்களை எழுதுங்கள்

ஆவணங்களை எழுதுதல்

BeeWare-க்கான உங்கள் ஆவணப் பங்களிப்பை எழுதப் பின்பற்ற வேண்டிய படிகள் இவை.

ஆவணங்களை எழுதத் தொடங்குவதற்கு முன், உங்களால் ஆவணங்களை உருவாக்க முடியும் என்பதையும், நீங்கள் ஒரு கிளைகளில் வேலை செய்கிறீர்கள் என்பதையும் உறுதிப்படுத்திக் கொள்ளுங்கள்.

தற்போதுள்ள ஆவணங்களைப் புதுப்பித்தல்

நீங்கள் ஏற்கனவே உள்ள ஆவணங்களைத் திருத்தினால், /docs/en கோப்பகத்தில் அந்தக் கோப்பை நீங்கள் கண்டறிய வேண்டும். கோப்பு அமைப்பு பக்க அமைப்பைப் பின்பற்றுகிறது, எனவே ஆவண URL-ஐப் பயன்படுத்தி நீங்கள் கோப்பைக் கண்டறியலாம்.

புதிய ஆவணத்தைச் சேர்த்தல்

நீங்கள் ஒரு புதிய ஆவணத்தைச் சேர்த்தால், இன்னும் சில படிகள் உள்ளன.

நீங்கள் docs/en கோப்பகத்திற்குள் பொருத்தமான இடத்தில் ஆவணத்தை உருவாக்க வேண்டும். விவாதத்திற்காக, நீங்கள் new_doc.md என்ற கோப்புப் பெயரில் ஒரு புதிய ஆவணத்தைச் சேர்க்கிறீர்கள் என்று கொள்வோம்.

பின்னர், உங்கள் புதிய கோப்பைச் சேர்க்க docs/en/SUMMARY.md கோப்பை நீங்கள் புதுப்பிக்க வேண்டும். SUMMARY.md கோப்பு அடிப்படையில் docs/en கோப்பக அமைப்பைப் பிரதிபலிக்கும் வகையில் ஒழுங்கமைக்கப்பட்டுள்ளது, ஆனால், மிக முக்கியமாக, இது இடது பக்கப்பட்டியின் அமைப்பை நேரடியாகத் தீர்மானிக்கிறது. நீங்கள் new_doc.md-ஐச் சேர்க்க விரும்பும் பிரிவைக் கண்டறிந்தால், அங்கு ஒரு வைல்ட்கார்டு பாதை பட்டியலிடப்பட்டிருந்தால், SUMMARY.md-இல் எதையும் மாற்றத் தேவையில்லை. எடுத்துக்காட்டாக:

- கோப்பகப் பாதை/*

நீங்கள் new_doc.md-ஐச் சேர்க்க விரும்பும் பகுதி தனிப்பட்ட மார்க்அப் இணைப்புகளின் பட்டியலாக இருந்தால், உங்கள் இணைப்பிற்கு ஒரு வெளிப்படையான இணைப்பைச் சேர்க்க வேண்டும். உதாரணமாக:

- [எனது புதிய ஆவணம்](new_doc.md)

உங்கள் ஆவணங்களை எழுதுதல்

நீங்கள் இப்போது விரும்பிய கோப்பை உங்கள் எடிட்டரில் திறந்து, எழுதத் தொடங்கலாம்.

BeeWare-க்கான ஆவணங்களை எழுதுவதற்கான எங்கள் வழிகாட்டுதல்களை விவரிக்கும் ஒரு ஆவணப்படுத்தல் பாணி வழிகாட்டி எங்களிடம் உள்ளது.

உங்கள் புதிய ஆவணங்களைப் பற்றி நீங்கள் திருப்தி அடைந்தவுடன், உங்கள் முன்மொழியப்பட்ட மாற்றங்களுடன் ஒரு புல் கோரிக்கையைச் சமர்ப்பிக்கலாம்.

மாற்றக் குறிப்பைச் சேர்க்கவும்

வெளியீட்டுக் குறிப்புகளுக்கான மாற்றத் தகவலைச் சேர்த்தல்

பல BeeWare கருவிகள் ஒவ்வொரு வெளியீட்டிற்கான வெளியீட்டுக் குறிப்புகளை உருவாக்க உதவுவதற்காக towncrier என்பதைப் பயன்படுத்துகின்றன. பொருந்தக்கூடிய கருவிகளில் ஒன்றிற்கு நீங்கள் ஒரு புல் ரிக்குவெஸ்டைச் சமர்ப்பிக்கும்போது, அதில் ஒரு மாற்றக் குறிப்பு சேர்க்கப்பட வேண்டும் - இந்த மாற்றக் குறிப்பு, செய்யப்பட்ட மாற்றத்தை விவரிக்கும் வெளியீட்டுக் குறிப்புகளில் உள்ள ஒரு உள்ளீடாக மாறும்.

ஒவ்வொரு புல் கோரிக்கையிலும், அந்தப் புல் கோரிக்கையால் செயல்படுத்தப்பட்ட மாற்றத்தைப் பற்றிய ஒரு சுருக்கமான விளக்கத்தை வழங்கும் changes/ கோப்பகத்தில் குறைந்தது ஒரு கோப்பாவது இருக்க வேண்டும். மாற்றக் குறிப்பு, <id>.<fragment type>.md என்ற வடிவத்தில் உள்ள ஒரு கோப்பில் மார்க்அப் வடிவத்தில் இருக்க வேண்டும். நீங்கள் முன்மொழிகின்ற மாற்றம், ஏற்கனவே ஒரு சிக்கல் எண் உள்ள பிழைத்திருத்தமாக இருந்தாலோ அல்லது ஒரு அம்சமாக இருந்தாலோ, அந்த சிக்கலின் எண்ணே ஐடியாக இருக்கும். மாற்றத்திற்கு தொடர்புடைய சிக்கல் எதுவும் இல்லையென்றால், PR எண்ணை ஐடியாகப் பயன்படுத்தலாம். பல் ரிக்வெஸ்டை நீங்கள் புஷ் செய்யும் வரை இந்த PR எண்ணை உங்களால் அறிய முடியாது, எனவே முதல் CI பாஸ் towncrier சோதனையில் தோல்வியடையும்; மாற்றக் குறிப்பைச் சேர்த்து ஒரு PR புதுப்பிப்பை புஷ் செய்யவும், அதன் பிறகு CI பாஸ் ஆகும்.

ஐந்து துண்டு வகைகள் உள்ளன:

  • feature: PR ஆனது, முன்பு சாத்தியமில்லாத ஒரு புதிய நடத்தை அல்லது திறனைச் சேர்க்கிறது (எ.கா., ஒரு புதிய பேக்கேஜிங் வடிவத்திற்கு ஆதரவைச் சேர்ப்பது, அல்லது ஏற்கனவே உள்ள பேக்கேஜிங் வடிவத்தில் ஒரு புதிய அம்சத்தைச் சேர்ப்பது);
  • bugfix: PR ஆனது தற்போதைய செயலாக்கத்தில் உள்ள ஒரு பிழையை சரிசெய்கிறது;
  • doc: PR ஆவணப்படுத்தலில் ஒரு குறிப்பிடத்தக்க முன்னேற்றம்;
  • removal; PR ஆனது BeeWare API-இல் பின்னோக்கி இணக்கமற்ற மாற்றத்தைக் குறிக்கிறது; அல்லது
  • misc; ஒரு சிறிய அல்லது நிர்வாக மாற்றம் (எ.கா., எழுத்துப்பிழை திருத்துதல், ஒரு சிறிய மொழி விளக்கம், அல்லது ஒரு சார்பு பதிப்பைப் புதுப்பித்தல்), இது வெளியீட்டுக் குறிப்புகளில் அறிவிக்கப்பட வேண்டிய அவசியமில்லை.

மாற்றக் குறிப்பில் உள்ள இந்த விளக்கம், பயனரின் கண்ணோட்டத்தில் மாற்றத்தின் ஒரு உயர் மட்ட "சந்தைப்படுத்தல்" சுருக்கமாக இருக்க வேண்டுமே தவிர, ஆழமான தொழில்நுட்ப விளக்கமாகவோ அல்லது செயல்படுத்தல் விவரமாகவோ இருக்கக்கூடாது. இது ஒரு கமிட் செய்தியிலிருந்து வேறுபட்டது - ஒரு கமிட் செய்தி, எதிர்கால டெவலப்பர்கள் ஒரு மாற்றத்திற்கான காரணத்தைப் பின்பற்றும் வகையில் என்ன செய்யப்பட்டது என்பதை விவரிக்கிறது; மாற்றக் குறிப்பு என்பது உள்நாட்டு விவரங்கள் பற்றி அறிந்திருக்க வாய்ப்பில்லாத பயனர்களின் நலனுக்காகக் கொடுக்கப்படும் விளக்கமாகும்.

உதாரணமாக, நீங்கள் திட்டப் பெயரிடுதல் தொடர்பான ஒரு பிழையைச் சரிசெய்தால், கமிட் செய்தியின் வாசகம் இவ்வாறு இருக்கலாம்:

எண்களில் தொடங்கும் திட்டப் பெயர்களைத் தடுக்க, வலுவான ரெகுலர் எக்ஸ்பிரஷன் சோதனையைப் பயன்படுத்தவும்.

அதற்குரிய மாற்றக் குறிப்பு ஏறக்குறைய இவ்வாறு இருக்கும்:

திட்டப் பெயர்கள் இனி எண் கொண்டு தொடங்க முடியாது.

சில PR-கள் பல அம்சங்களை அறிமுகப்படுத்தும், பல பிழைகளை சரிசெய்யும், அல்லது பல பின்னோக்கிய இணக்கமற்ற மாற்றங்களை அறிமுகப்படுத்தும். அப்படியானால், அந்த PR-ல் பல மாற்றக் குறிப்பு கோப்புகள் இருக்கலாம். இரண்டு ஃபிராக்மென்ட் வகைகளை ஒரே ஐடி-யுடன் தொடர்புபடுத்த வேண்டியிருந்தால், நீங்கள் ஒரு எண் சார்ந்த பின்னொட்டைச் சேர்க்கலாம். உதாரணமாக, PR 789, டிக்கெட் 123-ல் விவரிக்கப்பட்ட ஒரு அம்சத்தைச் சேர்த்து, டிக்கெட் 234-ல் விவரிக்கப்பட்ட ஒரு பிழையை சரிசெய்து, மேலும் இரண்டு பின்னோக்கி இணக்கமற்ற மாற்றங்களையும் செய்திருந்தால், உங்களிடம் 4 மாற்றக் குறிப்புக் கோப்புகள் இருக்கலாம்:

  • 123.feature.md
  • 234.bugfix.md
  • 789.removal.1.md
  • 789.removal.2.md

towncrier மற்றும் துண்டு வகைகள் பற்றிய கூடுதல் தகவல்களுக்கு News Fragments-ஐப் பார்க்கவும். changes களஞ்சியத்தின் BeeWare கோப்பகத்தில் உள்ள செய்தித் துண்டுகளின் தற்போதைய எடுத்துக்காட்டுகளையும் நீங்கள் காணலாம். இந்த கோப்புறை காலியாக இருந்தால், BeeWare சமீபத்தில் ஒரு புதிய வெளியீட்டை வெளியிட்டிருக்கலாம்; ஒவ்வொரு வெளியீட்டுடனும் வெளியீட்டுக் குறிப்புகளை புதுப்பிக்க, மாற்றக் குறிப்புக் கோப்புகள் நீக்கப்பட்டு இணைக்கப்படுகின்றன. தேவையான கருத்துருப் பாணியைக் காண அந்தக் கோப்பைப் பார்க்கலாம்; உங்கள் மாற்றக் குறிப்புகளை எவ்வாறு வடிவமைப்பது என்பதைக் காண சமீபத்தில் ஒன்றிணைக்கப்பட்ட PR-களை பார்க்கலாம்.

பல் ரிக்வெஸ்டைச் சமர்ப்பிக்கவும்

புல் ரிக்வெஸ்டைச் சமர்ப்பித்தல்

இப்போது உங்கள் மாற்றங்கள் அனைத்தையும் கமிட் செய்துவிட்டதால், நீங்கள் ஒரு புல் கோரிக்கையைச் சமர்ப்பிக்கத் தயாராக உள்ளீர்கள். உங்கள் மதிப்பாய்வு செயல்முறை தடையின்றி நடைபெறுவதை உறுதிசெய்ய, நீங்கள் எடுக்க வேண்டிய சில படிகள் உள்ளன.

முன்-அர்ப்பணிப்புடன் பணியாற்றுதல்

நீங்கள் எந்த மாற்றத்தையும் கமிட் செய்யும்போது, ப்ரீ-கமிட் தானாகவே இயங்கும். கமிட்டில் ஏதேனும் சிக்கல்கள் கண்டறியப்பட்டால், இது உங்கள் கமிட்டைத் தோல்வியடையச் செய்யும். முடிந்தவரை, ப்ரீ-கமிட் கண்டறிந்த சிக்கல்களைச் சரிசெய்யத் தேவையான மாற்றங்களைச் செய்யும். பின்வரும் எடுத்துக்காட்டில், ruff சரிபார்ப்பு மூலம் ஒரு குறியீடு வடிவமைப்புச் சிக்கல் கண்டறியப்பட்டது:

(.venv) $ git add some/interesting_file.py
(.venv) $ git commit -m "Minor change"
check toml...............................................................Passed
check yaml...............................................................Passed
check for case conflicts.................................................Passed
check docstring is first.................................................Passed
fix end of files.........................................................Passed
trim trailing whitespace.................................................Passed
ruff format..............................................................Failed
- hook id: ruff-format
- files were modified by this hook

1 file reformatted, 488 files left unchanged

ruff check...............................................................Passed
codespell................................................................Passed

(.venv) $ git add some/interesting_file.py
(.venv) $ git commit -m "Minor change"
check toml...............................................................Passed
check yaml...............................................................Passed
check for case conflicts.................................................Passed
check docstring is first.................................................Passed
fix end of files.........................................................Passed
trim trailing whitespace.................................................Passed
ruff format..............................................................Failed
- hook id: ruff-format
- files were modified by this hook

1 file reformatted, 488 files left unchanged

ruff check...............................................................Passed
codespell................................................................Passed

(.venv) C:\...>git add some/interesting_file.py
(.venv) C:\...>git commit -m "Minor change"
check toml...............................................................Passed
check yaml...............................................................Passed
check for case conflicts.................................................Passed
check docstring is first.................................................Passed
fix end of files.........................................................Passed
trim trailing whitespace.................................................Passed
ruff format..............................................................Failed
- hook id: ruff-format
- files were modified by this hook

1 file reformatted, 488 files left unchanged

ruff check...............................................................Passed
codespell................................................................Passed

இந்த நேர்வில், ruff தானாகவே சிக்கலைச் சரிசெய்தது; எனவே முன்-சமர்ப்பிப்புச் சரிபார்ப்புகளின் விளைவாக மாற்றியமைக்கப்பட்ட எந்தவொரு கோப்புகளையும் மீண்டும் சேர்த்து, மாற்றத்தை மீண்டும் சமர்ப்பிக்கலாம். இருப்பினும், சில சரிபார்ப்புகளுக்கு நீங்கள் கைமுறையாக மாற்றங்களைச் செய்ய வேண்டியிருக்கும். அந்த மாற்றங்களைச் செய்தவுடன், மாற்றியமைக்கப்பட்ட கோப்புகளை மீண்டும் சேர்த்து, மீண்டும் சமர்ப்பிக்கவும்.

(.venv) $ git add some/interesting_file.py
(.venv) $ git commit -m "Minor change"
check toml...............................................................Passed
check yaml...............................................................Passed
check for case conflicts.................................................Passed
check docstring is first.................................................Passed
fix end of files.........................................................Passed
trim trailing whitespace.................................................Passed
ruff format..............................................................Passed
ruff check...............................................................Passed
codespell................................................................Passed
[bugfix e3e0f73] Minor change
1 file changed, 4 insertions(+), 2 deletions(-)

(.venv) $ git add some/interesting_file.py
(.venv) $ git commit -m "Minor change"
check toml...............................................................Passed
check yaml...............................................................Passed
check for case conflicts.................................................Passed
check docstring is first.................................................Passed
fix end of files.........................................................Passed
trim trailing whitespace.................................................Passed
ruff format..............................................................Passed
ruff check...............................................................Passed
codespell................................................................Passed
[bugfix e3e0f73] Minor change
1 file changed, 4 insertions(+), 2 deletions(-)

(.venv) C:\...>git add some\interesting_file.py
(.venv) C:\...>git commit -m "Minor change"
check toml...............................................................Passed
check yaml...............................................................Passed
check for case conflicts.................................................Passed
check docstring is first.................................................Passed
fix end of files.........................................................Passed
trim trailing whitespace.................................................Passed
ruff format..............................................................Passed
ruff check...............................................................Passed
codespell................................................................Passed
[bugfix e3e0f73] Minor change
1 file changed, 4 insertions(+), 2 deletions(-)

எல்லாம் முடிந்ததும், கமிட் இறுதி செய்யப்பட்டது என்பதைக் குறிக்கும் ஒரு செய்தியைக் காண்பீர்கள், மேலும் உங்கள் git log-ல் உங்கள் கமிட் மிகச் சமீபத்திய சேர்ப்பாகக் காண்பிக்கப்படும். இப்போது நீங்கள் GitHub-க்கு புஷ் செய்யத் தயாராக உள்ளீர்கள்.

உங்கள் மாற்றங்களை GitHub-க்கு அனுப்பி, உங்கள் புல் கோரிக்கையை உருவாக்குங்கள்.

நீங்கள் GitHub-க்கு முதல் முறையாக புஷ் செய்யும்போது, ஒரு URL வழங்கப்படும், அது உங்களை நேரடியாக ஒரு புதிய புல் கோரிக்கையை உருவாக்க GitHub பக்கத்திற்கு அழைத்துச் செல்லும். அந்த URL-ஐப் பின்பற்றி உங்கள் புல் கோரிக்கையை உருவாக்கவும்.

பின்வருவது, URL முன்னிலைப்படுத்தப்பட்ட நிலையில், push-இல் நீங்கள் எதிர்பார்க்கக்கூடிய ஒன்றின் உதாரணத்தைக் காட்டுகிறது.

(.venv) $ git push
Enumerating objects: 15, done.
Counting objects: 100% (15/15), done.
Delta compression using up to 24 threads
Compressing objects: 100% (6/6), done.
Writing objects: 100% (8/8), 689 bytes | 689.00 KiB/s, done.
Total 8 (delta 4), reused 0 (delta 0), pack-reused 0 (from 0)
remote: Resolving deltas: 100% (4/4), completed with 4 local objects.
remote:
remote: Create a pull request for 'fix-win11-build' on GitHub by visiting:
remote:      https://github.com/<your GitHub username>/BeeWare/pull/new/fix-win11-build
remote:
To https://github.com/<your GitHub username>/BeeWare.git
 * [new branch]      fix-win11-build -> fix-win11-build

(.venv) $ git push
Enumerating objects: 15, done.
Counting objects: 100% (15/15), done.
Delta compression using up to 24 threads
Compressing objects: 100% (6/6), done.
Writing objects: 100% (8/8), 689 bytes | 689.00 KiB/s, done.
Total 8 (delta 4), reused 0 (delta 0), pack-reused 0 (from 0)
remote: Resolving deltas: 100% (4/4), completed with 4 local objects.
remote:
remote: Create a pull request for 'fix-win11-build' on GitHub by visiting:
remote:      https://github.com/<your GitHub username>/BeeWare/pull/new/fix-win11-build
remote:
To https://github.com/<your GitHub username>/BeeWare.git
 * [new branch]      fix-win11-build -> fix-win11-build

(.venv) C:\...>git push
Enumerating objects: 15, done.
Counting objects: 100% (15/15), done.
Delta compression using up to 24 threads
Compressing objects: 100% (6/6), done.
Writing objects: 100% (8/8), 689 bytes | 689.00 KiB/s, done.
Total 8 (delta 4), reused 0 (delta 0), pack-reused 0 (from 0)
remote: Resolving deltas: 100% (4/4), completed with 4 local objects.
remote:
remote: Create a pull request for 'fix-win11-build' on GitHub by visiting:
remote:      https://github.com/<your GitHub username>/BeeWare/pull/new/fix-win11-build
remote:
To https://github.com/<your GitHub username>/BeeWare.git
 * [new branch]      fix-win11-build -> fix-win11-build

நீங்கள் ஏற்கனவே தற்போதைய கிளை (current branch)-ஐ GitHub-க்குத் தள்ளியிருந்தால், நீங்கள் URL-ஐ மீண்டும் பெறமாட்டீர்கள். இருப்பினும், PR உருவாக்கும் URL-ஐப் பெறுவதற்கு வேறு வழிகளும் உள்ளன:

  • அப்ஸ்ட்ரீம் ரெபாசிட்டரிக்குச் சென்று, "புல் கோரிக்கைகள்" என்பதைக் கிளிக் செய்து, அதைத் தொடர்ந்து "புதிய புல் கோரிக்கை" என்பதைக் கிளிக் செய்யவும். பின்னர், உங்கள் புல் கோரிக்கையை நீங்கள் சமர்ப்பிக்க விரும்பும் இடத்திலிருந்து தேர்ந்தெடுக்கவும்.
  • நீங்கள் சமீபத்தில் புஷ் செய்திருந்தால், அப்ஸ்ட்ரீம் ரெபாசிட்டரிக்குச் சென்று, கோப்புகளின் பட்டியலுக்கு மேலே உள்ள, ரெப்போவில் "சமீபத்திய புஷ்கள்" இருந்தன என்பதைக் குறிக்கும் பேனரைக் கண்டறிந்து, "ஒப்பிட்டு & புல் கோரிக்கை" பொத்தானைக் கிளிக் செய்யவும்.
  • PR உருவாக்கும் பக்கத்தை வலை உலாவியில் திறக்க, GitHub CLI gh pr create --web கட்டளையைப் பயன்படுத்தவும்.

GitHub CLI: gh

GitHub, (https://cli.github.com/) கட்டளை மூலம் உங்கள் டெர்மினலில் இருந்தே GitHub-இன் பல அம்சங்களை அணுக gh என்ற கருவியை வழங்குகிறது. GitHub CLI ஆவணங்கள் அனைத்து அம்சங்களையும் உள்ளடக்கியுள்ளது.

ஜிஎச் பிஆர் கிரியேட்

உங்கள் புல் ரிக்குவஸ்டை உருவாக்க, வெறும் gh pr create கட்டளையைப் பயன்படுத்த வேண்டாம். BeeWare திட்டங்கள் புல் ரிக்குவஸ்டுகளுக்கு ஒரு வார்ப்புருவைப் பயன்படுத்துகின்றன, மேலும் அனைத்து பங்களிப்புகளும் இந்த வார்ப்புருவைப் பின்பற்ற வேண்டும் என நாங்கள் எதிர்பார்க்கிறோம். gh pr create கட்டளை இந்த வார்ப்புருவின் பயன்பாட்டைத் தவிர்த்துவிடுகிறது.

இழு கோரிக்கை உள்ளடக்கம்

ஒரு புல் ரிக்வெஸ்ட் தலைப்பு தகவல் நிறைந்ததாகவும், தெளிவாகவும், சுருக்கமாகவும் இருக்க வேண்டும். முடிந்தால் அதைச் சுருக்கமாக வைத்திருக்க முயற்சி செய்யுங்கள், ஆனால் தேவைப்பட்டால் நீண்ட தலைப்புகளும் ஏற்றுக்கொள்ளத்தக்கவை. ஒரு நல்ல PR தலைப்பு, எந்தச் சூழலும் அறியாத ஒருவருக்குக் கூட, உங்கள் PR மூலம் எந்தப் பிழை அல்லது அம்சம் செயல்படுத்தப்பட்டுள்ளது என்பது பற்றிய ஒரு திடமான யோசனையை வழங்க வேண்டும்.

உங்கள் புல் ரிக்வெஸ்ட் கட்டாயமாக BeeWare புல் ரிக்வெஸ்ட் டெம்ப்ளேட்டை பின்பற்ற வேண்டும். நீங்கள் GitHub வலை இடைமுகத்தைப் பயன்படுத்தி உங்கள் புல் ரிக்வெஸ்ட்டை உருவாக்கியிருந்தால், இந்த டெம்ப்ளேட் உங்கள் புல் ரிக்வெஸ்ட் விளக்கத்திற்கான ஒரு தொடக்கப் புள்ளியாக வழங்கப்படும். தற்செயலாக இந்த வார்ப்புருவைப் பயன்படுத்தாமல் ஒரு புல் ரிக்வெஸ்டை உருவாக்கினால், வார்ப்புரு உள்ளடக்கத்தைச் சேர்க்க புல் ரிக்வெஸ்டைத் திருத்தலாம் - ஆனால் வார்ப்புரு உள்ளடக்கம் கட்டாயமாக வழங்கப்பட்டு, பொருத்தமாக நிரப்பப்பட வேண்டும்.

PR-இல் உள்ள மாற்றங்களை PR விளக்கம் தெளிவாகப் பிரதிபலிக்க வேண்டும். எந்தச் சூழலும் அறியாத ஒருவரால் உங்கள் விளக்கத்தைப் படித்து, ஏன் இந்த மாற்றம் செய்யப்படுகிறது என்பது பற்றிய ஒரு முழுமையான புரிதலைப் பெற முடிந்திருக்க வேண்டும். நகைச்சுவைகள், சொற்றொடர்கள், பேச்சு வழக்குகள் மற்றும் தேவையற்ற வடிவமைப்பு போன்றவற்றைத் தவிர்க்கவும், உதாரணமாக, பெரிய எழுத்துக்களில் எழுதுதல் அல்லது அதிகப்படியான நிறுத்தற்குறிகளைப் பயன்படுத்துதல்; இது உங்கள் PR-இல் என்ன நடக்கிறது என்பதற்கான ஒரு நேரடியான விளக்கமாக இருக்க வேண்டும், மேலும் இத்தகைய விஷயங்களைத் தவிர்ப்பது மற்றவர்கள் எளிதில் புரிந்துகொள்ள உதவுகிறது.

ஏதேனும் மறுஉருவாக்க நிகழ்வுகள் இருந்தாலோ, அல்லது நீங்கள் பயன்படுத்திய ஏதேனும் சோதனை நடைமுறைகள் PR-ல் ஏற்கனவே உள்ள மாற்றங்களின் ஒரு பகுதியாக இல்லாவிட்டாலோ, அவை விளக்கப்பட்டு PR-ல் சேர்க்கப்பட வேண்டும். அந்த விளக்கத்தில் அவற்றை எவ்வாறு இயக்குவது மற்றும் விரும்பிய முடிவை மீண்டும் பெற என்ன செய்ய வேண்டும் என்பன அடங்கியிருக்க வேண்டும்.

உங்கள் புல் ரிக்குவஸ்ட் சிக்கல் #1234-ஐத் தீர்க்கும் பட்சத்தில், உங்கள் புல் ரிக்குவஸ்ட் விளக்கத்தில் Fixes #1234 என்ற உரையைச் சேர்க்க வேண்டும். இது, புல் ரிக்குவஸ்ட் ஒன்றிணைக்கப்படும்போது, அந்தச் சிக்கல் தானாகவே மூடப்படுவதற்கு வழிவகுக்கும். இதே #1234 சொற்றொடையைப் பயன்படுத்தி நீங்கள் மற்ற கலந்துரையாடல்கள், சிக்கல்கள் அல்லது புல் கோரிக்கைகளைக் குறிப்பிடலாம். ஒரு எண்ணுக்கு முன்னால் - குறியைச் சேர்ப்பதன் மூலம் நீங்கள் வேறு ஒரு களஞ்சியத்தில் உள்ள ஒரு சிக்கலைக் குறிப்பிடலாம். உதாரணமாக, python/cpython#1234 என்பது CPython களஞ்சியத்தில் உள்ள சிக்கல் 1234-ஐக் குறிக்கும்.

AI கருவிகள், சோதனைத் தொகுப்பை எவ்வாறு இயக்குவது என்பதை விவரிக்கும் "சோதனை நெறிமுறை" அல்லது ஒரு பிழை ஏன் சரிசெய்யப்பட வேண்டும் என்பதற்கான "காரணம்" போன்ற, அதிகப்படியான, உதவாத புல் ரிக்வெஸ்ட் செய்திகளை எழுதுவதற்கு குறிப்பாக முனைகின்றன. உங்கள் PR-ஐ உருவாக்க நீங்கள் ஒரு AI கருவியைப் பயன்படுத்தினால், புல் ரிக்வெஸ்ட் விளக்கம் சுருக்கமாகவும், மதிப்பாய்வு செயல்முறைக்கு உதவக்கூடிய தகவல்களை மட்டுமே கொண்டிருப்பதை உறுதி செய்வதற்கும் நீங்களே பொறுப்பு. உதாரணமாக, சோதனைத் தொகுப்பை (test suite) எவ்வாறு இயக்குவது என்பதை விவரிக்கும் "சோதனை நெறிமுறை" அல்லது ஒரு பிழை ஏன் சரிசெய்யப்பட வேண்டும் என்பதற்கான "காரணம்" போன்ற விவரங்களை நீங்கள் சேர்க்க வேண்டியதில்லை. அளவுக்கு அதிகமாக நீளமான புல் ரிக்வெஸ்ட் உள்ளடக்கங்கள், முக்கிய குழுவின் வரையறுக்கப்பட்ட வளங்களைக் கருத்தில் கொள்ளாததால், உங்கள் புல் ரிக்வெஸ்ட் மதிப்பாய்வு செய்யப்படாமலேயே மூடப்படுவதற்கு வழிவகுக்கும்.

பீவேர் புல் ரிக்வெஸ்ட் வார்ப்புரு

BeeWare பல் ரிக்வெஸ்ட் வார்ப்புரு விருப்பத்திற்குரியது அல்ல. அனைத்து பல் ரிக்வெஸ்ட்களும் இந்த வார்ப்புருவைப் பின்பற்ற வேண்டும். உங்கள் பல் ரிக்வெஸ்டில் "PR சரிபார்ப்புப் பட்டியல்" பகுதி இல்லை என்றாலோ, அல்லது சரிபார்ப்புப் பெட்டி கேள்விகளுக்கான உங்கள் பதில்கள் முழுமையற்றதாகவோ அல்லது முரண்பாடாகவோ இருந்தாலோ, உங்கள் பல் ரிக்வெஸ்ட் மதிப்பாய்வு செய்யப்படாது. உங்கள் புல் கோரிக்கையை உருவாக்க நீங்கள் ஒரு AI கருவியைப் பயன்படுத்தியிருந்தால், நீங்கள் தொடர்புடைய பெட்டியை கட்டாயமாக தேர்வு செய்ய வேண்டும், மேலும் "Assisted-by:" என்ற வரிசையில் விவரங்களை வழங்க வேண்டும்.

தொடர் ஒருங்கிணைப்பு

தொடர் ஒருங்கிணைப்பு, அல்லது CI, என்பது உங்கள் புல் ரிக்குவஸ்டில் தானியங்கு சரிபார்ப்புகளை இயக்கும் செயல்முறையாகும். இதில் குறியீடு சரியாக வடிவமைக்கப்பட்டுள்ளதா என்பதை உறுதி செய்வது போன்ற எளிய சரிபார்ப்புகள் அடங்கும்; ஆனால் இது சோதனைத் தொகுப்பை இயக்குவது மற்றும் ஆவணங்களை உருவாக்குவதும் அடங்கும்.

CI தோல்விகளுக்கு வழிவகுக்கும் எண்ணற்ற மாற்றங்கள் உள்ளன. பொதுவாகச் சொல்வதானால், CI-ல் தேர்ச்சி பெறாத ஒரு PR-ஐ நாங்கள் மதிப்பாய்வு செய்ய மாட்டோம். நீங்கள் ஒரு புல் ரிக்வெஸ்டை உருவாக்கி, CI தோல்வியுற்றால், அது தேர்ச்சி பெறும் வரை நாங்கள் உங்கள் மதிப்பாய்வைத் தொடங்க மாட்டோம். உங்கள் மாற்றங்கள் தோல்விக்கு வழிவகுத்தால், அதற்கான காரணத்தைக் கண்டறிந்து, சிக்கலைத் தீர்ப்பது உங்கள் பொறுப்பாகும்.

CI தோல்வியடையும் போது, "சில சரிபார்ப்புகள் வெற்றிகரமாக அமையவில்லை" என்ற தலைப்பின் கீழ், PR பக்கத்தின் கீழே தோல்வி இணைப்புகள் தோன்றும். தோல்வியுற்ற சரிபார்ப்புகளின் பட்டியலை நீங்கள் காண்பீர்கள், மேலும், தேர்ச்சி பெற்ற சரிபார்ப்புகளும் இருந்தால், அவை அனைத்து சரிபார்ப்புகளின் பட்டியலின் மேலே தோன்றும். நீங்கள் தோல்வி இணைப்பைக் கிளிக் செய்தால், அது உங்களை லாகிற்கு அழைத்துச் செல்லும். தோல்விக்கான காரணத்தைக் கண்டறியத் தேவையான அனைத்துத் தகவல்களையும் அந்த லாக் பெரும்பாலும் வழங்கும். லாக்கை முழுமையாகப் படித்து, தோல்வி ஏன் ஏற்படுகிறது என்பதைக் கண்டறிய முயற்சி செய்யுங்கள், பின்னர் அதைத் தீர்க்கத் தேவையானதைச் செய்யுங்கள்.

அவ்வப்போது, உங்கள் மாற்றங்களுடன் தொடர்பில்லாத காரணங்களுக்காக ஒரு CI சரிபார்ப்பு தோல்வியடையலாம். இது CI சரிபார்ப்பை இயக்கும் கணினியில் உள்ள ஒரு சிக்கல் காரணமாகவோ, அல்லது ஒரு CI சரிபார்ப்பு நிலையற்றதாக இருப்பதால்வோ இருக்கலாம். நீங்கள் ஒரு தோல்வியைக் கண்டால், அது உங்கள் மாற்றங்களுடன் தொடர்பில்லாதது என்று உங்களுக்கு உறுதியாகத் தெரிந்தால், அந்தக் கருத்தை உங்கள் PR-இல் சேர்க்கவும், நாங்கள் அதை ஆராய்வோம்.

ஒரு புதிய CI ஓட்டத்தைத் தூண்ட, உங்கள் கிளைக்கு புதிய மாற்றங்களைத் தள்ள வேண்டும்.

CI-ஐ கடக்க உங்களுக்கு உதவி தேவைப்படும் சூழ்நிலையில் நீங்கள் இருந்தால், PR-இல் ஒரு கருத்தைப் பதிவிட்டு எங்களுக்குத் தெரியப்படுத்துங்கள், நாங்கள் உதவ எங்களால் முடிந்ததைச் செய்வோம்.

pre-commit மற்றும் towncrier சரிபார்ப்புகள்

pre-commit அல்லது towncrier சரிபார்ப்புகளில் ஏதேனும் ஒன்று தோல்வியுற்றால், அது CI சரிபார்ப்புகளில் மீதமுள்ள பெரும்பாலானவற்றை இயங்குவதிலிருந்து தடுக்கும். முழுமையான சரிபார்ப்புகளும் இயங்குவதற்கு முன்பு, பொருந்தக்கூடிய சிக்கல்களை நீங்கள் சரிசெய்ய வேண்டும்.

எங்களிடம் வரையறுக்கப்பட்ட CI வளங்கள் உள்ளன. நீங்கள் ஒவ்வொரு முறையும் பிராஞ்சிற்கு புஷ் செய்யும்போது, CI தொடங்கும் என்பதைப் புரிந்துகொள்வது அவசியம். நீங்கள் பல மாற்றங்களைச் செய்யப் போகிறீர்கள் என்றால், அந்த மாற்றங்களை உள்ளூரில் செய்து, அனைத்தையும் ஒரே நேரத்தில் புஷ் செய்வது நல்லது. CI ஒரு தொகுதியில் உள்ள மிகச் சமீபத்திய கமிட்டில் மட்டுமே இயங்கும், இது எங்கள் CI அமைப்பின் சுமையைக் குறைக்கிறது.

உங்கள் PR சமர்ப்பிக்கும் செயல்முறை, அது CI-ஐ கடக்கும் வரை அல்லது அது ஏன் கடக்கவில்லை என்பதற்கான விளக்கத்தை நீங்கள் வழங்கும் வரை முழுமையடையாது.

உங்கள் புல் ரிக்வெஸ்ட் மதிப்பாய்வு செய்யப்படுவதற்கு முன்பு, அதற்கு மாற்றக் குறிப்பு போன்ற கூடுதல் உள்ளடக்கம் தேவைப்படலாம்.