ನೆಟ್‌ವರ್ಕ್‌ನ ಹೊರಗೆ Python wheel ನಿರ್ಮಿಸಿ, ಒಳಗೆ ಪ್ರಕಟಿಸಿ

ನಿಮ್ಮ ಬಳಿ ಈಗಾಗಲೇ wheel ಉತ್ಪಾದಿಸುವ ಬಿಲ್ಡ್ ಕೆಲಸವಿದೆ, ಮತ್ತು ಅದನ್ನು ಸ್ವೀಕರಿಸಬೇಕಾದ ಖಾಸಗಿ ರಿಪೊಸಿಟರಿ ಇದೆ. ತಪ್ಪು ಎಂದರೆ ಎರಡನೇ ಕೆಲಸವು ಶಾಖೆಯಿಂದ ಮತ್ತೆ ನಿರ್ಮಿಸಲು ಬಿಟ್ಟು ಫಲಿತಾಂಶವನ್ನು ಅದೇ ಬಿಡುಗಡೆ ಎಂದು ಕರೆಯುವುದು. ಪರೀಕ್ಷಿಸಿದ ಫೈಲನ್ನೇ ಸಾಗಿಸಿ, ಡೈಜೆಸ್ಟ್‌ನಿಂದ ಅದಕ್ಕೆ ಹೆಸರಿಡಿ, ಮತ್ತು ಅಪ್‌ಲೋಡ್ ರುಜುವಾತನ್ನು ಒಳಗೇ ಇರಿಸಿ. ಕೆಳಗಿನ ವಿವರಣೆ ಒಂದು ಆರ್ಟಿಫ್ಯಾಕ್ಟ್ ಅನ್ನು ಸಾರ್ವಜನಿಕ CI ರನ್ನರ್‌ನಿಂದ ಆಂತರಿಕ ಪ್ರಕಾಶಕರವರೆಗೆ ಅನುಸರಿಸುತ್ತದೆ.

ಮೂಲವು ಈಗಾಗಲೇ ಇರುವಲ್ಲಿಯೇ ನಿರ್ಮಿಸಿ

ಈಗಾಗಲೇ ಮೂಲ, ಉಪಕರಣ ಸರಣಿ ಮತ್ತು ಪರೀಕ್ಷಾ ಗುಂಪನ್ನು ಹೊಂದಿರುವ ಕೆಲಸದಲ್ಲಿ ಬಿಲ್ಡ್ ಚಲಾಯಿಸಿ. ಖಾಸಗಿ ರಿಪೊಸಿಟರಿಯ ಬಗ್ಗೆ ಯಾವುದೂ ಆ ಕೆಲಸವು ಅದನ್ನು ತಲುಪಬೇಕೆಂದು ಒತ್ತಾಯಿಸುವುದಿಲ್ಲ. ಯೋಜನೆ ಈಗಾಗಲೇ ಬಳಸುವ ಪರಿಸರದಲ್ಲಿ ಬಿಲ್ಡ್ ಫ್ರಂಟೆಂಡ್ ಸ್ಥಾಪಿಸಿ, ನಂತರ ಯೋಜನೆ ಎರಡೂ ವಿತರಣಾ ಸ್ವರೂಪಗಳನ್ನು ಕಳುಹಿಸಿದರೆ ಎರಡನ್ನೂ ಉತ್ಪಾದಿಸಿ.

python -m build --sdist --wheel --outdir dist
python -m twine check dist/*

ಔಟ್‌ಪುಟ್ ಡೈರೆಕ್ಟರಿಯನ್ನು ಚಿಕ್ಕದಾಗಿ ಮತ್ತು ಒಂದೇ ಬಾರಿಗೆ ಬಳಸುವಂತೆ ಇರಿಸಿ. ಮುಂದಕ್ಕೆ ಒಯ್ಯಲು ಯೋಗ್ಯವಾದದ್ದು ಮುಂದಿನ ಕೆಲಸ ಪ್ರಕಟಿಸುವ ಫೈಲ್‌ಗಳು ಮತ್ತು ಅವುಗಳ ಹ್ಯಾಶ್‌ಗಳು ಮಾತ್ರ. ಉಳಿದೆಲ್ಲವನ್ನೂ, ವರ್ಚುವಲ್ ಪರಿಸರ ಮತ್ತು ಕ್ಯಾಶ್ ಸೇರಿದಂತೆ, ದಾಖಲಾದ ಮೂಲ ಮರುರೂಪಣೆಯಿಂದ ಮತ್ತೆ ನಿರ್ಮಿಸಬಹುದು. ತೆಳುವಾದ ಆರ್ಟಿಫ್ಯಾಕ್ಟ್ ಪರಿಶೀಲನೆಗೂ ಸುಲಭ, ಏಕೆಂದರೆ ಅದರಲ್ಲಿನ ಪ್ರತಿ ಫೈಲ್ ಯಾರಾದರೂ ಪರೀಕ್ಷಿಸಬಹುದಾದ ಫೈಲ್ ಆಗಿದೆ.

ಅವನ್ನು ಯಾವುದು ಉತ್ಪಾದಿಸಿತು ಎಂಬುದನ್ನು ದಾಖಲಿಸಿ: ಫೈಲ್ ಹೆಸರುಗಳಿಂದ ಪ್ಯಾಕೇಜ್ ಹೆಸರು ಮತ್ತು ಆವೃತ್ತಿ, ಮೂಲ ಮರುರೂಪಣೆ, ಮತ್ತು ಅವನ್ನು ಸೃಷ್ಟಿಸಿದ ವರ್ಕ್‌ಫ್ಲೋ ರನ್. ಕೇವಲ ಆವೃತ್ತಿ ಸರಣಿಯು ಫೈಲ್ ಅನ್ನು ಗುರುತಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಅದೇ ಆವೃತ್ತಿಯನ್ನು ಬೇರೆ ಬೇರೆ commit‌ಗಳಿಂದ ಎರಡು ಬಾರಿ ನಿರ್ಮಿಸಬಹುದು. ಆರ್ಟಿಫ್ಯಾಕ್ಟ್ ವಿವರಣೆಯಲ್ಲಿ ಫೈಲ್ ಹೆಸರುಗಳ ಪಕ್ಕ ಮರುರೂಪಣೆ ಬರೆಯಿರಿ, ಮತ್ತು ಆ ದಾಖಲೆಯನ್ನು ಹಸ್ತಾಂತರದ ಭಾಗವೆಂದು ಪರಿಗಣಿಸಿ.

ಬೈಟ್‌ಗಳನ್ನು ಸಾಗಿಸಿ, ಮತ್ತೆ ನಿರ್ಮಿಸುವ ಸೂಚನೆಗಳನ್ನಲ್ಲ

ಎರಡನೇ ಬಿಲ್ಡ್ ಎರಡನೇ ಉತ್ಪನ್ನ. ಸಮಯ ಮುದ್ರೆಗಳು, ಬಂಡಲ್ ಮಾಡಿದ ಅವಲಂಬನೆಗಳು ಮತ್ತು ಉಪಕರಣ ಆವೃತ್ತಿಗಳು ಬೈಟ್‌ಗಳನ್ನು ಬದಲಿಸಬಹುದು, ಆದ್ದರಿಂದ ಮರುನಿರ್ಮಾಣಕ್ಕೆ ತನ್ನದೇ ಪರೀಕ್ಷಾ ಸಾಕ್ಷ್ಯ ಮತ್ತು ತನ್ನದೇ ಪರಿಶೀಲನೆ ಬೇಕು. ಬದಲಿಗೆ ಪರಿಶೀಲಿಸಿದ ಫೈಲ್‌ಗಳನ್ನೇ ಮುಂದಕ್ಕೆ ಒಯ್ಯಿರಿ.

ವಿತರಣಾ ಫೈಲ್‌ಗಳನ್ನು ನಿಮ್ಮ CI ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಒದಗಿಸುವ ಆರ್ಟಿಫ್ಯಾಕ್ಟ್ ಸ್ಟೋರ್‌ಗೆ ಅಪ್‌ಲೋಡ್ ಮಾಡಿ, ಮತ್ತು ಆಂತರಿಕ ಕೆಲಸಕ್ಕೆ ಶಾಖೆಯ ಹೆಸರಿನ ಬದಲು ಆ ನಿರ್ದಿಷ್ಟ ಆರ್ಟಿಫ್ಯಾಕ್ಟ್‌ನ ಉಲ್ಲೇಖ ನೀಡಿ.

sha256sum dist/*.whl dist/*.tar.gz
# keep the digests beside the run id in the artifact description

ನಿಮ್ಮ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಸಹಿ ಮಾಡಿದ ಮೂಲವನ್ನು ಬೆಂಬಲಿಸಿದರೆ, ಅದನ್ನು ಆರ್ಟಿಫ್ಯಾಕ್ಟ್ ಪ್ರಮಾಣೀಕರಿಸಲು ಮತ್ತು ನಂತರ ನಿರೀಕ್ಷಿತ ರಿಪೊಸಿಟರಿ, ವರ್ಕ್‌ಫ್ಲೋ ಮತ್ತು ಮೂಲ ಮರುರೂಪಣೆಯನ್ನು ಪರಿಶೀಲಿಸಲು ಕೇಳಿ. GitHub‌ನ ಪ್ರಮಾಣೀಕರಣ ದಾಖಲೆ ಆ ರೂಪದ ಹೇಳಿಕೆಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ. ಮಾನ್ಯ ಸಹಿ ಮೂಲದ ಸಾಕ್ಷ್ಯ, ಅದು ದುರ್ಬಲತೆ ಸ್ಕ್ಯಾನ್ ಅಲ್ಲ ಮತ್ತು ಅಧಿಕಾರ ನಿರ್ಣಯವೂ ಅಲ್ಲ.

ಅಪ್‌ಲೋಡ್‌ಗೆ ಮೊದಲು ಒಳಗೆ ಪರಿಶೀಲಿಸಿ

ಆಂತರಿಕ ಕೆಲಸವು ಸ್ವೀಕರಿಸಿದ ಫೈಲ್ ಅನುಮೋದಿತ ಫೈಲ್ ಎಂದು ಪರಿಶೀಲಿಸುವುದರಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಡೈಜೆಸ್ಟ್‌ಗಳನ್ನು ಬಿಲ್ಡ್ ಕೆಲಸದ ದಾಖಲೆಯೊಂದಿಗೆ ಹೋಲಿಸಿ, ಬಂದದ್ದರಿಂದ ಮತ್ತೆ ಲೆಕ್ಕಹಾಕಿದ ಮೌಲ್ಯದೊಂದಿಗಲ್ಲ.

sha256sum -c digests.txt
python -m twine check dist/*

ನಂತರ ಮೆಟಾಡೇಟಾ ಓದಿ. ಪ್ಯಾಕೇಜ್ ಹೆಸರು, ಆವೃತ್ತಿ ಮತ್ತು ಘೋಷಿತ ಅವಲಂಬನೆಗಳು ನೀವು ಅನುಮೋದಿಸಿದ ಪರಿಶೀಲನೆಗೆ ಹೊಂದಬೇಕು. ಹೆಸರು ಸರಿ ಕಾಣುವ ಆದರೆ ಅವಲಂಬನೆ ಪಿನ್‌ಗಳು ಬದಲಾಗಿರುವ wheel ಬೇರೆ ಪ್ಯಾಕೇಜ್, ಅದೇ ಲೇಬಲ್ ಧರಿಸಿದೆ. ಮೆಟಾಡೇಟಾ ಜಾರಿದರೆ, ಆರ್ಟಿಫ್ಯಾಕ್ಟ್ ಅನ್ನು ಅನುಮೋದಿತವಲ್ಲ ಎಂದು ಪರಿಗಣಿಸಿ ಮತ್ತು ಯಾವ ಬಿಲ್ಡ್ ಅದನ್ನು ಉತ್ಪಾದಿಸಿತು ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯಿರಿ.

ಡೈಜೆಸ್ಟ್‌ಗಳು ಹೊಂದದಿದ್ದರೆ ನಿಲ್ಲಿಸಿ. ಅಪ್‌ಲೋಡ್ ಮಾಡಬೇಡಿ, ಮತ್ತು ಫೈಲ್ ಅನ್ನು ಅಲ್ಲಿಯೇ ಮತ್ತೆ ನಿರ್ಮಿಸಿ ಸರಿಪಡಿಸಬೇಡಿ; ಅದು ಸಾಗಣೆಯಲ್ಲಿ ಏನೋ ಬದಲಾಯಿತು ಎಂಬ ಸಾಕ್ಷ್ಯವನ್ನು ಅಳಿಸುತ್ತದೆ. ಹೊಂದಿಕೆಯಾಗದಿರುವುದು ಆರ್ಟಿಫ್ಯಾಕ್ಟ್ ಸ್ಟೋರ್, ಡೌನ್‌ಲೋಡ್ ಹಂತ ಅಥವಾ ದಾಖಲೆ ತಪ್ಪು ಎಂದರ್ಥ, ಮತ್ತು ಬಿಡುಗಡೆ ಪ್ರಕಟವಾಗುವ ಮೊದಲು ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದಕ್ಕೂ ವಿವರಣೆ ಬೇಕು.

ನಕಲಿ ಆವೃತ್ತಿಯ ಉತ್ತರವನ್ನು ನಿಭಾಯಿಸಿ

ಖಾಸಗಿ ರಿಪೊಸಿಟರಿಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಇರುವ ಆವೃತ್ತಿಯನ್ನು ಮೇಲೆ ಬರೆಯಲು ನಿರಾಕರಿಸುತ್ತವೆ, ಮತ್ತು ಆ ನಿರಾಕರಣೆ ಒಂದು ವೈಶಿಷ್ಟ್ಯ. ಆವೃತ್ತಿ ಇರುವ ಕಾರಣ ಅಪ್‌ಲೋಡ್ ವಿಫಲವಾದಾಗ, ಆ ಆವೃತ್ತಿಗೆ ರಿಪೊಸಿಟರಿಯ ದಾಖಲೆಯನ್ನು ಪರಿಶೀಲಿಸಿ ಮತ್ತು ಅದು ಇಟ್ಟುಕೊಂಡಿರುವ ಫೈಲ್‌ಗಳನ್ನು ನೀವು ಪ್ರಕಟಿಸಲು ಉದ್ದೇಶಿಸಿದ ಡೈಜೆಸ್ಟ್‌ಗಳೊಂದಿಗೆ ಹೋಲಿಸಿ.

ಇರುವ ಆವೃತ್ತಿ ಎಂದರೆ ಹಿಂದಿನ ಅಪ್‌ಲೋಡ್ ಯಶಸ್ವಿಯಾಯಿತು ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆ ಕಳೆದುಹೋಯಿತು, ಅಥವಾ ಯಾರೋ ಅದೇ ಸಂಖ್ಯೆಯ ಅಡಿಯಲ್ಲಿ ಬೇರೆ ವಿಷಯ ಪ್ರಕಟಿಸಿದರು ಎಂದಾಗಿರಬಹುದು.

ಆವೃತ್ತಿಯನ್ನು ಅಳಿಸಬೇಡಿ, ಮತ್ತು ದೋಷವನ್ನು ದಾಟಲು ಹೊಸ ಸಂಖ್ಯೆ ಕಲ್ಪಿಸಬೇಡಿ. ಸಂಗ್ರಹಿಸಿದ ವಿಷಯ ಸ್ವೀಕಾರಾರ್ಹವೇ ಎಂದು ಬಿಡುಗಡೆ ಮಾಲೀಕರೊಂದಿಗೆ ನಿರ್ಧರಿಸಿ, ನಂತರ ಫಲಿತಾಂಶ ದಾಖಲಿಸಿ. ವಿಷಯ ಭಿನ್ನವಾಗಿದ್ದರೆ, ಅದು ಆವೃತ್ತಿ ಸಮಸ್ಯೆ, ಪೈಪ್‌ಲೈನ್ ಸಮಸ್ಯೆ ಅಲ್ಲ.

ಅಪ್‌ಲೋಡ್ ರುಜುವಾತನ್ನು ಒಂದೇ ಬದಿಯಲ್ಲಿ ಇರಿಸಿ

ರಿಪೊಸಿಟರಿ ರುಜುವಾತುಗಳು ಆಂತರಿಕ ಪ್ರಕಾಶಕರಿಗೆ ಮಾತ್ರ ಬೇಕು, ಮತ್ತು ಅಪ್‌ಲೋಡ್ ಇರುವವರೆಗೆ ಮಾತ್ರ. ಟೋಕನ್ ಅನ್ನು ಗುರಿ ರಿಪೊಸಿಟರಿ ಮತ್ತು ಅಪ್‌ಲೋಡ್ ಕಾರ್ಯಾಚರಣೆಗಳಿಗೆ ಸೀಮಿತಗೊಳಿಸಿ, ಆಂತರಿಕ ವ್ಯವಸ್ಥೆಯ ರಹಸ್ಯ ಸಂಗ್ರಹದಲ್ಲಿ ಇರಿಸಿ, ಮತ್ತು ಬಿಲ್ಡ್ ಕೆಲಸದಿಂದ ಸಂಪೂರ್ಣವಾಗಿ ಹೊರಗಿಡಿ. ಬಿಲ್ಡ್ ಕೆಲಸ ಪ್ರಕಟಿಸಬಲ್ಲದಾದರೆ, ಬಿಲ್ಡ್ ಬದಲಿಸಬಲ್ಲ ಯಾರಾದರೂ ಪ್ರಕಟಿಸಬಲ್ಲರು.

ಯಾವ ಆಂತರಿಕ ವರ್ಕ್‌ಫ್ಲೋಗಳು ಪ್ರಕಾಶಕರನ್ನು ಪ್ರಾರಂಭಿಸಬಹುದು ಎಂಬುದನ್ನೂ ಸೀಮಿತಗೊಳಿಸಿ. ಕಡ್ಡಾಯ ಅನುಮೋದನೆಯೊಂದಿಗೆ ಕೈಯಿಂದ ಪ್ರಚೋದಕ ಬಿಡುಗಡೆಗಳಿಗೆ ಸೂಕ್ತ ಡೀಫಾಲ್ಟ್; ಯಾವುದೇ ಶಾಖೆಗೆ push ಅಲ್ಲ.

ಪೂರ್ಣಗೊಂಡ ಬಿಡುಗಡೆಯು ಮೂರು ವಿಷಯಗಳನ್ನು ಬಿಡಬೇಕು: ವಿತರಣಾ ಫೈಲ್‌ಗಳು, ಮೂಲ ಮರುರೂಪಣೆಯೊಂದಿಗೆ ಅವುಗಳ ಡೈಜೆಸ್ಟ್‌ಗಳು, ಮತ್ತು ಅದೇ ಆವೃತ್ತಿ ತೋರಿಸುವ ರಿಪೊಸಿಟರಿ ದಾಖಲೆ.