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

ஒரு சிக்கலைச் சரிசெய்தல்

BeeWare Docs Tools என்பது அறியப்பட்ட சிக்கல்கள் பட்டியலைக் கண்காணிக்கிறது. இவற்றில் ஏதேனும் சிக்கல்கள் வேலை செய்யத் தகுதியானவை.

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

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

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

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

ஒரு சிக்கலுக்குத் தீர்வு பங்களித்தல்

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

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

BeeWare Docs Tools-க்கு பங்களிப்பதற்கு, நீங்கள் ஒரு மேம்பாட்டுச் சூழலை அமைக்க வேண்டும்.

முன்நிபந்தனைகள்

பின்வரும் முன்நிபந்தனைகளை நீங்கள் நிறுவ வேண்டும்.

BeeWare Docs Tools க்கு Python 3.10+ தேவை. மெய்நிகர் சூழல்களை நிர்வகிப்பதற்கான ஒரு முறையையும் (எ.கா. venv) நீங்கள் பயன்படுத்த வேண்டும்.

பின்வருவதை இயக்கி, நீங்கள் நிறுவியுள்ள பைத்தானின் பதிப்பைச் சரிபார்க்கலாம்:

பைத்தான் 3.8.10

நீங்கள் பைத்தனின் ஒன்றுக்கு மேற்பட்ட பதிப்புகளை நிறுவியிருந்தால், நீங்கள் python3 என்பதை ஒரு குறிப்பிட்ட பதிப்பு எண்ணுடன் (எ.கா., python3.13) மாற்ற வேண்டியிருக்கலாம்.

சமீபத்தில் வெளியிடப்பட்ட பைத்தானின் பதிப்பைத் (அதாவது, ".0" அல்லது ".1" என்ற நுண் பதிப்பு எண்ணைக் கொண்ட பதிப்புகள், எ.கா., 3.14.0) தவிர்க்கப் பரிந்துரைக்கிறோம். ஏனெனில், macOS-இல் பைத்தானை ஆதரிக்கத் தேவையான கருவிகள், சமீபத்தில் வெளியிடப்பட்ட நிலையான பைத்தான் பதிப்புகளுக்குப் பொதுவாகக் கிடைப்பதில்லை அல்லது தாமதமாகக் கிடைக்கின்றன.

BeeWare Docs Tools க்கு Python 3.10+ தேவை. மெய்நிகர் சூழல்களை நிர்வகிப்பதற்கான ஒரு முறையையும் (எ.கா. venv) நீங்கள் பயன்படுத்த வேண்டும்.

பின்வருவதை இயக்கி, நீங்கள் நிறுவியுள்ள பைத்தானின் பதிப்பைச் சரிபார்க்கலாம்:

பைத்தான் 3.8.10

நீங்கள் பைத்தனின் ஒன்றுக்கு மேற்பட்ட பதிப்புகளை நிறுவியிருந்தால், நீங்கள் python3 என்பதை ஒரு குறிப்பிட்ட பதிப்பு எண்ணுடன் (எ.கா., python3.13) மாற்ற வேண்டியிருக்கலாம்.

சமீபத்தில் வெளியிடப்பட்ட பைத்தானின் பதிப்பைத் (அதாவது, ".0" அல்லது ".1" என்ற நுண் பதிப்பு எண்ணைக் கொண்ட பதிப்புகள், எ.கா., 3.14.0) தவிர்க்குமாறு நாங்கள் பரிந்துரைக்கிறோம். ஏனெனில், லினக்ஸில் பைத்தானை ஆதரிக்கத் தேவையான கருவிகள், சமீபத்தில் வெளியிடப்பட்ட நிலையான பைத்தான் பதிப்புகளுக்குப் பொதுவாகக் கிடைப்பதில்லை.

BeeWare Docs Tools க்கு Python 3.10+ தேவை. மெய்நிகர் சூழல்களை நிர்வகிப்பதற்கான ஒரு முறையையும் (எ.கா. venv) நீங்கள் பயன்படுத்த வேண்டும்.

பின்வருவதை இயக்கி, நீங்கள் நிறுவியுள்ள பைத்தானின் பதிப்பைச் சரிபார்க்கலாம்:

C:\...>py -3 --version

உங்களிடம் பைத்தனின் ஒன்றுக்கு மேற்பட்ட பதிப்புகள் நிறுவப்பட்டிருந்தால், நீங்கள் -3-ஐ ஒரு குறிப்பிட்ட பதிப்பு எண்ணுடன் (எ.கா., -python3.13) மாற்ற வேண்டியிருக்கலாம்.

சமீபத்தில் வெளியிடப்பட்ட பைத்தானின் பதிப்பைத் (அதாவது, ".0" அல்லது ".1" என்ற நுண் பதிப்பு எண்ணைக் கொண்ட பதிப்புகள், எ.கா., 3.14.0) தவிர்க்குமாறு நாங்கள் பரிந்துரைக்கிறோம். ஏனெனில், விண்டோஸில் பைத்தானை ஆதரிக்கத் தேவையான கருவிகள், சமீபத்தில் வெளியிடப்பட்ட நிலையான பைத்தான் பதிப்புகளுக்குப் பொதுவாகக் கிடைப்பதில்லை அல்லது தாமதமாகக் கிடைக்கின்றன.

உங்கள் மேம்பாட்டுச் சூழலை அமைக்கவும்

BeeWare Docs Tools-க்கான உங்கள் மேம்பாட்டுச் சூழலை அமைப்பதற்கான பரிந்துரைக்கப்பட்ட வழி, ஒரு மெய்நிகர்ச் சூழலைப் பயன்படுத்தி, பின்னர் BeeWare Docs Tools-இன் மேம்பாட்டுப் பதிப்பையும் அதன் சார்புநிலைத் தொகுப்புகளையும் நிறுவுவதாகும்.

BeeWare Docs Tools களஞ்சியத்தை நகலெடுக்கவும்

அடுத்து, GitHub-இல் உள்ள BeeWare Docs Tools பக்கத்திற்குச் செல்லவும், மேலும், நீங்கள் ஏற்கனவே செய்யவில்லை என்றால், கிடங்கை உங்கள் கணக்கில் ஃபோர்க் செய்யவும். அடுத்து, உங்கள் ஃபோர்க்கில் உள்ள "<> Code" பொத்தானைக் கிளிக் செய்யவும். உங்கள் கணினியில் GitHub டெஸ்க்டாப் பயன்பாடு நிறுவப்பட்டிருந்தால், நீங்கள் "Open with GitHub Desktop" என்பதைத் தேர்ந்தெடுக்கலாம்; இல்லையெனில், வழங்கப்பட்ட HTTPS URL-ஐ நகலெடுத்து, கட்டளை வரியைப் பயன்படுத்தி உங்கள் கணினிக்கு ரெபாசிட்டரியைக் குளோன் செய்ய அதைப் பயன்படுத்தவும்:

BeeWare Docs Tools களஞ்சியத்தை ஃபோர்க் செய்து, பின்னர்:

$ git clone https://github.com/<உங்கள் பயனர் பெயர்>/beeware-docs-tools.git

(உங்கள் GitHub பயனர் பெயரை இங்கே மாற்றவும்)

BeeWare Docs Tools களஞ்சியத்தை ஃபோர்க் செய்து, பின்னர்:

$ git clone https://github.com/<உங்கள் பயனர் பெயர்>/beeware-docs-tools.git

(உங்கள் GitHub பயனர் பெயரை இங்கே மாற்றவும்)

BeeWare Docs Tools களஞ்சியத்தை ஃபோர்க் செய்து, பின்னர்:

C:\...>git clone https://github.com/<உங்கள் பயனர் பெயர்>/beeware-docs-tools.git

(உங்கள் GitHub பயனர் பெயரை இங்கே மாற்றவும்)

மேல்நிலை களஞ்சியத்தை அமைக்கவும்

உங்கள் ஃபோர்க்கை கிளோன் செய்த பிறகு, BeeWare ரெபாசிட்டரியை ஒரு upstream ரிமோட்டாகச் சேர்க்கவும். இது உங்கள் உள்ளூர் கிளோனுக்கு அசல் ரெபாசிட்டரியின் ஒரு குறிப்பை வழங்குகிறது, காலப்போக்கில் புதுப்பிப்புகளை ஒத்திசைப்பதை எளிதாக்குகிறது.

Toga மற்றும் Briefcase போன்ற கருவிகள் துல்லியமான பதிப்பு எண்களைத் தீர்க்க upstream இலிருந்து வரும் டேக்குகளும் உங்களுக்குத் தேவைப்படும்:

$ git remote add upstream https://github.com/beeware/beeware-docs-tools.git
$ git fetch --tags upstream

$ git remote add upstream https://github.com/beeware/beeware-docs-tools.git
$ git fetch --tags upstream

C:\...>git remote add upstream https://github.com/beeware/beeware-docs-tools.git
C:\...>git fetch --tags upstream

உங்கள் ஃபோர்க்கிலும் அந்த டேக்குகளைச் சேர்க்க விரும்பினால், அவற்றை நீங்கள் புஷ் செய்யலாம்:

$ கிட் புஷ் --டேக்ஸ்

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

ஒரு மெய்நிகர் சூழலை உருவாக்கவும்

மெய்நிகர் சூழலை அமைக்க மற்றும் மேம்படுத்த pip, பின்வருவனவற்றை இயக்கவும்:

$ cd beeware-docs-tools
$ python3 -m venv .venv
$ source .venv/bin/activate
(.venv) $ python -m pip install -U pip

$ cd beeware-docs-tools
$ python3 -m venv .venv
$ source .venv/bin/activate
(.venv) $ python -m pip install -U pip

C:\...>cd beeware-docs-tools
C:\...>py -3 -m venv .venv
C:\...>.venv\Scripts\activate
(.venv) $ python -m pip install -U pip

உங்கள் கட்டளையின் முன்னால் இப்போது ஒரு (.venv) முன்னொட்டு இருக்க வேண்டும்.

நிறுவவும் BeeWare Docs Tools

இப்போது உங்களிடம் மூலக் குறியீடு இருப்பதால், உங்கள் மேம்பாட்டுச் சூழலில் (https://setuptools.pypa.io/en/latest/userguide/development_mode.html) ஐ ஒரு [திருத்தக்கூடிய நிறுவல்]BeeWare Docs Tools செய்யலாம். பின்வரும் கட்டளையை இயக்கவும்:

(.venv) $ python -m pip install -U -e . --group dev

(.venv) $ python -m pip install -U -e . --group dev

(.venv) C:\...>python -m pip install -U -e . --group dev

முன்-அர்ப்பணிப்பை இயக்கவும்

BeeWare Docs Tools எளிமையான சிக்கல்களைக் கண்டறியவும், குறியீட்டு வடிவமைப்பைத் தரப்படுத்தவும் pre-commit என்ற கருவியைப் பயன்படுத்துகிறது. எந்தவொரு git commit-ஐயும் இறுதி செய்வதற்கு முன்பு, தானாகவே தொடர்ச்சியான code linters-களை இயக்கும் ஒரு git hook-ஐ நிறுவுவதன் மூலம் இது செயல்படுகிறது. pre-commit-ஐ இயக்க, பின்வருவனவற்றை இயக்கவும்:

(.venv) $ pre-commit install
pre-commit installed at .git/hooks/pre-commit

(.venv) $ pre-commit install
pre-commit installed at .git/hooks/pre-commit

(.venv) C:\...>pre-commit install
pre-commit installed at .git/hooks/pre-commit

இப்போது நீங்கள் BeeWare Docs Tools ஹேக்கிங் செய்யத் தயாராக உள்ளீர்கள்!

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

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

உங்கள் மாற்றத்தில் வேலை செய்யத் தொடங்குவதற்கு முன், நீங்கள் ஒரு கிளை உருவாக்கியுள்ளீர்கள் என்பதை உறுதிப்படுத்திக் கொள்ளுங்கள். இயல்பாக, உங்கள் களஞ்சியப் பிளக்கை நீங்கள் நகலெடுக்கும்போது, உங்கள் main கிளையில் நீங்கள் சரிபார்க்கப்படுவீர்கள். இது BeeWare Docs Tools-இன் 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
சிக்கலை மீண்டும் உருவாக்கவும்

ஒரு சிக்கலை மீண்டும் உருவாக்குதல்

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

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

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

குறியீட்டுப் பிழைகள்

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

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

ஆவணங்களில் உள்ள பிழைகள்

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

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

சிக்கலைப் புதுப்பிக்கவும்

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

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

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

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

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

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

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

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

குறியீட்டை எழுதுங்கள், இயக்கவும், சோதிக்கவும்

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(.venv) $ tox

(.venv) $ tox

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

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

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

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

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

வழக்கமாக, பல tox கட்டளைகள், BeeWare Docs Tools ஆதரிக்கும் ஒவ்வொரு 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 Docs Tools அதன் குறியீட்டுத் தொகுப்பில் 100% கிளை உள்ளடக்கத்தை பராமரிக்கிறது. நீங்கள் திட்டத்தில் குறியீட்டைச் சேர்க்கும்போது அல்லது மாற்றியமைக்கும்போது, நீங்கள் செய்யும் மாற்றங்களின் உள்ளடக்கத்தை உறுதிசெய்ய, சோதனைக் குறியீட்டைச் சேர்க்க வேண்டும்.

இருப்பினும், BeeWare Docs Tools பல தளங்களையும், பைத்தனின் பல பதிப்புகளையும் இலக்காகக் கொண்டுள்ளது, எனவே முழுமையான உள்ளடக்கத்தை ஒரே தளம் மற்றும் பைத்தான் பதிப்பில் சரிபார்க்க முடியாது. இதைச் சமாளிக்க, 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 Docs Tools-இன் ஆவணத்தில் ஏதேனும் மாற்றங்களைச் செய்வதற்கு முன், ஏற்கனவே உள்ள ஆவணத்தை உங்களால் உருவாக்க முடியும் என்பதை உறுதி செய்வது உதவியாக இருக்கும்.

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

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

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

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

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

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

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

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

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

(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 Docs Toolsயின் ஆவணங்கள் பல மொழிகளில் மொழிபெயர்க்கப்பட்டுள்ளன. ஆங்கில ஆவணங்களில் செய்யப்படும் புதுப்பிப்புகள், மற்ற மொழி பில்ட்களில் சிக்கல்களை ஏற்படுத்தக்கூடும். ஒரு புல் கோரிக்கையைச் சமர்ப்பிக்கும் முன், அனைத்து பில்ட்களும் சரியாக வேலை செய்கின்றனவா என்பதைச் சரிபார்ப்பது அவசியம்.

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

(வினைச்சொல்) $ 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 Docs Tools என்பது "லிண்டிங்" எனப்படும் பாணி மற்றும் வடிவமைப்புக்கான சில கூடுதல் சோதனைகளைச் செய்கிறது. லிண்ட் சோதனைகளை இயக்க:

(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 Tools-க்கான உங்கள் ஆவணப் பங்களிப்பை எழுதப் பின்பற்ற வேண்டிய படிகள் இவை.

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

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

நீங்கள் ஏற்கனவே உள்ள ஆவணங்களைத் திருத்தினால், /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 Docs Tools ஒவ்வொரு வெளியீட்டிற்கான வெளியீட்டுக் குறிப்புகளை உருவாக்க உதவுவதற்காக towncrier ஐப் பயன்படுத்துகிறது. நீங்கள் ஒரு புல் ரிக்குவெஸ்டைச் சமர்ப்பிக்கும்போது, அதில் ஒரு மாற்றக் குறிப்பு இருக்க வேண்டும் - இந்த மாற்றக் குறிப்பு, செய்யப்பட்ட மாற்றத்தை விவரிக்கும் வெளியீட்டுக் குறிப்புகளில் உள்ள ஒரு பதிவாக மாறும்.

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

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

  • feature: PR ஆனது, முன்பு சாத்தியமில்லாத ஒரு புதிய நடத்தை அல்லது திறனைச் சேர்க்கிறது (எ.கா., ஒரு புதிய பேக்கேஜிங் வடிவத்திற்கு ஆதரவைச் சேர்ப்பது, அல்லது ஏற்கனவே உள்ள பேக்கேஜிங் வடிவத்தில் ஒரு புதிய அம்சத்தைச் சேர்ப்பது);
  • bugfix: PR ஆனது தற்போதைய செயலாக்கத்தில் உள்ள ஒரு பிழையை சரிசெய்கிறது;
  • doc: PR ஆவணப்படுத்தலில் ஒரு குறிப்பிடத்தக்க முன்னேற்றம்;
  • removal; PR ஆனது BeeWare Docs Tools 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 Docs Tools கோப்பகத்தில் உள்ள செய்தித் துண்டுகளின் தற்போதைய எடுத்துக்காட்டுகளையும் நீங்கள் காணலாம். இந்த கோப்புறை காலியாக இருந்தால், BeeWare Docs Tools சமீபத்தில் ஒரு புதிய வெளியீட்டை வெளியிட்டிருக்கலாம்; ஒவ்வொரு வெளியீட்டுடனும் வெளியீட்டுக் குறிப்புகளை புதுப்பிக்க, மாற்றக் குறிப்புக் கோப்புகள் நீக்கப்பட்டு இணைக்கப்படுகின்றன. தேவையான கருத்துருப் பாணியைக் காண அந்தக் கோப்பைப் பார்க்கலாம்; உங்கள் மாற்றக் குறிப்புகளை எவ்வாறு வடிவமைப்பது என்பதைக் காண சமீபத்தில் ஒன்றிணைக்கப்பட்ட 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 Docs Tools/pull/new/fix-win11-build
remote:
To https://github.com/<your GitHub username>/BeeWare Docs Tools.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 Docs Tools/pull/new/fix-win11-build
remote:
To https://github.com/<your GitHub username>/BeeWare Docs Tools.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 Docs Tools/pull/new/fix-win11-build
remote:
To https://github.com/<your GitHub username>/BeeWare Docs Tools.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-ஐ கடக்கும் வரை அல்லது அது ஏன் கடக்கவில்லை என்பதற்கான விளக்கத்தை நீங்கள் வழங்கும் வரை முழுமையடையாது.

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