(ಬಹುತೇಕ) ಸಂಪೂರ್ಣ ಆರಂಭಿಕರಿಗಾಗಿ GitLab ನಲ್ಲಿ CI/CD ಗೆ ಮಾರ್ಗದರ್ಶಿ

ಅಥವಾ ವಿಶ್ರಾಂತಿ ಕೋಡಿಂಗ್‌ನ ಒಂದು ಸಂಜೆಯಲ್ಲಿ ನಿಮ್ಮ ಯೋಜನೆಗೆ ಸುಂದರವಾದ ಬ್ಯಾಡ್ಜ್‌ಗಳನ್ನು ಹೇಗೆ ಪಡೆಯುವುದು

ಬಹುಶಃ, ಕನಿಷ್ಠ ಒಂದು ಸಾಕುಪ್ರಾಣಿ ಯೋಜನೆಯನ್ನು ಹೊಂದಿರುವ ಪ್ರತಿಯೊಬ್ಬ ಡೆವಲಪರ್, ಒಂದು ಹಂತದಲ್ಲಿ ಸ್ಟೇಟಸ್‌ಗಳು, ಕೋಡ್ ಕವರೇಜ್, ನುಗೆಟ್‌ನಲ್ಲಿ ಪ್ಯಾಕೇಜ್‌ಗಳ ಆವೃತ್ತಿಗಳೊಂದಿಗೆ ಸುಂದರವಾದ ಬ್ಯಾಡ್ಜ್‌ಗಳಿಗಾಗಿ ಕಜ್ಜಿ ಪಡೆಯುತ್ತಾರೆ... ಮತ್ತು ಈ ಕಜ್ಜಿ ನನ್ನನ್ನು ಈ ಲೇಖನವನ್ನು ಬರೆಯಲು ಕಾರಣವಾಯಿತು. ಇದನ್ನು ಬರೆಯಲು ತಯಾರಿ ಮಾಡುವ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ, ನನ್ನ ಒಂದು ಯೋಜನೆಯಲ್ಲಿ ನಾನು ಈ ಸೌಂದರ್ಯವನ್ನು ಪಡೆದುಕೊಂಡೆ:

ಈ ಲೇಖನವು GitLab ನಲ್ಲಿ .Net Core ವರ್ಗ ಲೈಬ್ರರಿ ಯೋಜನೆಗಾಗಿ ನಿರಂತರ ಏಕೀಕರಣ ಮತ್ತು ವಿತರಣೆಯ ಮೂಲ ಸೆಟಪ್ ಅನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ, GitLab ಪುಟಗಳಿಗೆ ದಸ್ತಾವೇಜನ್ನು ಪ್ರಕಟಿಸುವುದು ಮತ್ತು Azure DevOps ನಲ್ಲಿ ಖಾಸಗಿ ಫೀಡ್‌ಗೆ ಬಿಲ್ಟ್ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಕಳುಹಿಸುವುದು.

ವಿಸ್ತರಣೆಯೊಂದಿಗೆ VS ಕೋಡ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿ ಪರಿಸರವಾಗಿ ಬಳಸಲಾಗಿದೆ. GitLab ಕೆಲಸದ ಹರಿವು (ಅಭಿವೃದ್ಧಿ ಪರಿಸರದಿಂದ ನೇರವಾಗಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳ ಫೈಲ್ ಅನ್ನು ಮೌಲ್ಯೀಕರಿಸಲು).

ಸಂಕ್ಷಿಪ್ತ ಪರಿಚಯ

ಸಿಡಿ - ನೀವು ತಳ್ಳಿದಾಗ ಮತ್ತು ಕ್ಲೈಂಟ್‌ನ ಎಲ್ಲವೂ ಈಗಾಗಲೇ ಕ್ರ್ಯಾಶ್ ಆಗಿದೆಯೇ?

CI/CD ಎಂದರೇನು ಮತ್ತು ಅದು ಏಕೆ ಬೇಕು - ನೀವು ಅದನ್ನು ಸುಲಭವಾಗಿ ಗೂಗಲ್ ಮಾಡಬಹುದು. GitLab ನಲ್ಲಿ ಪೈಪ್‌ಲೈನ್‌ಗಳನ್ನು ಸ್ಥಾಪಿಸುವ ಬಗ್ಗೆ ಸಂಪೂರ್ಣ ದಾಖಲಾತಿಯನ್ನು ಕಾಣಬಹುದು. ಅದು ಕಷ್ಟವೂ ಅಲ್ಲ.ಇಲ್ಲಿ ನಾನು ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಮತ್ತು ಸಾಧ್ಯವಾದರೆ, ಪಕ್ಷಿನೋಟದಿಂದ ವ್ಯವಸ್ಥೆಯ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ನಿಖರವಾಗಿ ವಿವರಿಸುತ್ತೇನೆ:

• ಡೆವಲಪರ್ ರೆಪೊಸಿಟರಿಗೆ ಬದ್ಧತೆಯನ್ನು ಕಳುಹಿಸುತ್ತಾರೆ, ಸೈಟ್ ಮೂಲಕ ವಿಲೀನ ವಿನಂತಿಯನ್ನು ರಚಿಸುತ್ತಾರೆ, ಅಥವಾ ಬೇರೆ ರೀತಿಯಲ್ಲಿ, ಸ್ಪಷ್ಟವಾಗಿ ಅಥವಾ ಸೂಚ್ಯವಾಗಿ, ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ,
• ನಿರ್ದಿಷ್ಟ ಸನ್ನಿವೇಶದಲ್ಲಿ ಪ್ರಾರಂಭಿಸಲು ಪರಿಸ್ಥಿತಿಗಳು ಅನುಮತಿಸುವ ಎಲ್ಲಾ ಕಾರ್ಯಗಳನ್ನು ಸಂರಚನೆಯಿಂದ ಆಯ್ಕೆ ಮಾಡಲಾಗುತ್ತದೆ,
• ಕಾರ್ಯಗಳನ್ನು ಅವುಗಳ ಹಂತಗಳಿಗೆ ಅನುಗುಣವಾಗಿ ಆಯೋಜಿಸಲಾಗಿದೆ,
• ಹಂತಗಳನ್ನು ಪ್ರತಿಯಾಗಿ ನಡೆಸಲಾಗುತ್ತದೆ - ಅಂದರೆ. ಸಮಾನಾಂತರ ಈ ಹಂತದ ಎಲ್ಲಾ ಕಾರ್ಯಗಳು ಪೂರ್ಣಗೊಂಡಿವೆ,
• ಒಂದು ಹಂತ ವಿಫಲವಾದರೆ (ಅಂದರೆ ಹಂತದಲ್ಲಿ ಕನಿಷ್ಠ ಒಂದು ಕಾರ್ಯ ವಿಫಲವಾದರೆ), ಪೈಪ್‌ಲೈನ್ ನಿಲ್ಲುತ್ತದೆ (ಬಹುತೇಕ ಯಾವಾಗಲೂ),
• ಎಲ್ಲಾ ಹಂತಗಳು ಯಶಸ್ವಿಯಾಗಿ ಪೂರ್ಣಗೊಂಡರೆ, ಪೈಪ್‌ಲೈನ್ ಯಶಸ್ವಿ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ.

ಹೀಗಾಗಿ, ನಾವು:

• ಪೈಪ್‌ಲೈನ್ - ಹಂತಗಳಲ್ಲಿ ಆಯೋಜಿಸಲಾದ ಕಾರ್ಯಗಳ ಒಂದು ಸೆಟ್, ಇದರಲ್ಲಿ ನೀವು ಪ್ಯಾಕೇಜ್ ಕೋಡ್ ಅನ್ನು ನಿರ್ಮಿಸಬಹುದು, ಪರೀಕ್ಷಿಸಬಹುದು, ಸಿದ್ಧಪಡಿಸಿದ ಜೋಡಣೆಯನ್ನು ಕ್ಲೌಡ್ ಸೇವೆಗೆ ನಿಯೋಜಿಸಬಹುದು, ಇತ್ಯಾದಿ.
• ಹಂತ (ಹಂತ) — ಪೈಪ್‌ಲೈನ್ ಸಂಘಟನೆಯ ಒಂದು ಘಟಕ, 1+ ಕಾರ್ಯವನ್ನು ಒಳಗೊಂಡಿದೆ,
• ಕಾರ್ಯ (ಕೆಲಸ) — ಪೈಪ್‌ಲೈನ್‌ನಲ್ಲಿರುವ ಕೆಲಸದ ಒಂದು ಘಟಕ. ಸ್ಕ್ರಿಪ್ಟ್ (ಅಗತ್ಯ), ಉಡಾವಣಾ ಪರಿಸ್ಥಿತಿಗಳು, ಕಲಾಕೃತಿ ಪ್ರಕಟಣೆ/ಕ್ಯಾಶಿಂಗ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಮತ್ತು ಇನ್ನೂ ಹೆಚ್ಚಿನದನ್ನು ಒಳಗೊಂಡಿದೆ.

ಅಂತೆಯೇ, CI/CD ಅನ್ನು ಸ್ಥಾಪಿಸುವಾಗ ಕಾರ್ಯವು ಕೋಡ್ ಮತ್ತು ಕಲಾಕೃತಿಗಳನ್ನು ನಿರ್ಮಿಸಲು, ಪರೀಕ್ಷಿಸಲು ಮತ್ತು ಪ್ರಕಟಿಸಲು ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಕ್ರಮಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಕಾರ್ಯಗಳ ಗುಂಪನ್ನು ರಚಿಸುವುದು.

ನಾವು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು: ಏಕೆ?

• GitLab ಏಕೆ?

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

• Azure DevOps ಪೈಪ್‌ಲೈನ್‌ಗಳು ಏಕೆ ಬೇಡ?

ಏಕೆಂದರೆ ಸೆಟಪ್ ಪ್ರಾಥಮಿಕವಾಗಿದೆ - ನೀವು ಕಮಾಂಡ್ ಲೈನ್ ಅನ್ನು ತಿಳಿದುಕೊಳ್ಳಬೇಕಾಗಿಲ್ಲ. ಬಾಹ್ಯ ಜಿಟ್ ಪೂರೈಕೆದಾರರೊಂದಿಗೆ ಏಕೀಕರಣವು ಒಂದೆರಡು ಕ್ಲಿಕ್‌ಗಳಷ್ಟಾಗುತ್ತದೆ, ರೆಪೊಸಿಟರಿಗೆ ಕಮಿಟ್‌ಗಳನ್ನು ಕಳುಹಿಸಲು SSH ಕೀಗಳನ್ನು ಆಮದು ಮಾಡಿಕೊಳ್ಳುವುದು ಸಹ ಸುಲಭ, ಟೆಂಪ್ಲೇಟ್ ಇಲ್ಲದೆಯೂ ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ಸುಲಭವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು.

ಆರಂಭಿಕ ಸ್ಥಾನ: ನಿಮ್ಮ ಬಳಿ ಏನು ಇದೆ ಮತ್ತು ನಿಮಗೆ ಏನು ಬೇಕು

ನಾವು ಹೊಂದಿದ್ದೇವೆ:

• GitLab ನಲ್ಲಿ ರೆಪೊಸಿಟರಿ.

ನಮಗೆ ಬೇಕು:

• ಪ್ರತಿ ವಿಲೀನ ವಿನಂತಿಗೆ ಸ್ವಯಂಚಾಲಿತ ನಿರ್ಮಾಣ ಮತ್ತು ಪರೀಕ್ಷೆ,
• ಪ್ರತಿ ವಿಲೀನ ವಿನಂತಿ ಮತ್ತು ಮಾಸ್ಟರ್‌ಗೆ ತಳ್ಳುವಿಕೆಗಾಗಿ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುವುದು, ಬದ್ಧತೆ ಸಂದೇಶದಲ್ಲಿ ಒಂದು ನಿರ್ದಿಷ್ಟ ಸಾಲು ಇದ್ದರೆ,
• ಸಂಗ್ರಹಿಸಿದ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು Azure DevOps ನಲ್ಲಿ ಖಾಸಗಿ ಫೀಡ್‌ಗೆ ಕಳುಹಿಸುವುದು,
• GitLab ಪುಟಗಳಲ್ಲಿ ದಸ್ತಾವೇಜನ್ನು ಸಂಕಲನ ಮತ್ತು ಪ್ರಕಟಣೆ,
• ಬ್ಯಾಡ್ಜ್‌ಗಳು!11

ವಿವರಿಸಿದ ಅವಶ್ಯಕತೆಗಳು ಈ ಕೆಳಗಿನ ಪೈಪ್‌ಲೈನ್ ಮಾದರಿಗೆ ಸಾವಯವವಾಗಿ ಹೊಂದಿಕೊಳ್ಳುತ್ತವೆ:

• ಹಂತ 1 - ಜೋಡಣೆ
  • ನಾವು ಕೋಡ್ ಅನ್ನು ಕಂಪೈಲ್ ಮಾಡಿ ಔಟ್‌ಪುಟ್ ಫೈಲ್‌ಗಳನ್ನು ಕಲಾಕೃತಿಗಳಾಗಿ ಪ್ರಕಟಿಸುತ್ತೇವೆ.
• ಹಂತ 2 - ಪರೀಕ್ಷೆ
  • ನಾವು ನಿರ್ಮಾಣ ಹಂತದಿಂದ ಕಲಾಕೃತಿಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತೇವೆ, ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸುತ್ತೇವೆ, ಕೋಡ್ ಕವರೇಜ್ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ.
• ಹಂತ 3 - ಕಳುಹಿಸುವುದು
  • ಕಾರ್ಯ 1 - ನ್ಯೂಗೆಟ್ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ನಿರ್ಮಿಸಿ ಮತ್ತು ಅದನ್ನು ಅಜುರೆ ಡೆವೊಪ್ಸ್‌ಗೆ ಕಳುಹಿಸಿ
  • ಕಾರ್ಯ 2 - ಮೂಲ ಕೋಡ್‌ನಲ್ಲಿ xmldoc ನಿಂದ ಸೈಟ್ ಅನ್ನು ನಿರ್ಮಿಸಿ ಮತ್ತು GitLab ಪುಟಗಳಲ್ಲಿ ಪ್ರಕಟಿಸಿ.

ಪ್ರಾರಂಭಿಸೋಣ!

ಸಂರಚನೆಯನ್ನು ಜೋಡಿಸುವುದು

ಖಾತೆಗಳನ್ನು ಸಿದ್ಧಪಡಿಸಲಾಗುತ್ತಿದೆ

1. ನಲ್ಲಿ ಖಾತೆಯನ್ನು ರಚಿಸಿ ಮೈಕ್ರೋಸಾಫ್ಟ್ ಅಜುರೆ

2. ಗೆ ಹೋಗಿ ಅಜುರೆ ಡೆವೊಪ್ಸ್

3. ಹೊಸ ಯೋಜನೆಯನ್ನು ರಚಿಸಿ

   1. ಹೆಸರು - ಯಾವುದೇ
   2. ಗೋಚರತೆ - ಯಾವುದೇ
      

4. ನೀವು ರಚಿಸು ಬಟನ್ ಅನ್ನು ಕ್ಲಿಕ್ ಮಾಡಿದಾಗ, ಪ್ರಾಜೆಕ್ಟ್ ಅನ್ನು ರಚಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮನ್ನು ಅದರ ಪುಟಕ್ಕೆ ಮರುನಿರ್ದೇಶಿಸಲಾಗುತ್ತದೆ. ಈ ಪುಟದಲ್ಲಿ, ನೀವು ಪ್ರಾಜೆಕ್ಟ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳಿಗೆ ಹೋಗುವ ಮೂಲಕ ಅನಗತ್ಯ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬಹುದು (ಎಡಭಾಗದಲ್ಲಿರುವ ಪಟ್ಟಿಯಲ್ಲಿ ಕೆಳಗಿನ ಲಿಂಕ್ -> ಅವಲೋಕನ -> ಅಜೂರ್ ಡೆವೊಪ್ಸ್ ಸೇವೆಗಳ ಬ್ಲಾಕ್)
   

5. ಅಟ್ರಿಫ್ಯಾಕ್ಟ್ಸ್‌ಗೆ ಹೋಗಿ, ಫೀಡ್ ರಚಿಸಿ ಕ್ಲಿಕ್ ಮಾಡಿ

   1. ಮೂಲದ ಹೆಸರನ್ನು ನಮೂದಿಸಿ
   2. ಗೋಚರತೆಯನ್ನು ಆಯ್ಕೆಮಾಡಿ
   3. ಪೆಟ್ಟಿಗೆಯನ್ನು ಗುರುತಿಸಬೇಡಿ ಸಾಮಾನ್ಯ ಸಾರ್ವಜನಿಕ ಮೂಲಗಳಿಂದ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಸೇರಿಸಿ, ಆದ್ದರಿಂದ ಮೂಲವು ನ್ಯೂಜೆಟ್ ಕ್ಲೋನ್ ಡಂಪ್ ಆಗಿ ಬದಲಾಗುವುದಿಲ್ಲ
      

6. ಫೀಡ್ ಮಾಡಲು ಕನೆಕ್ಟ್ ಕ್ಲಿಕ್ ಮಾಡಿ, ವಿಷುಯಲ್ ಸ್ಟುಡಿಯೋ ಆಯ್ಕೆಮಾಡಿ, ಮೆಷಿನ್ ಸೆಟಪ್ ಬ್ಲಾಕ್‌ನಿಂದ ಸೋರ್ಸ್ ಅನ್ನು ನಕಲಿಸಿ.
   

7. ಖಾತೆ ಸೆಟ್ಟಿಂಗ್‌ಗಳಿಗೆ ಹೋಗಿ, ವೈಯಕ್ತಿಕ ಪ್ರವೇಶ ಟೋಕನ್ ಆಯ್ಕೆಮಾಡಿ.
   

8. ಹೊಸ ಪ್ರವೇಶ ಟೋಕನ್ ರಚಿಸಿ

   1. ಹೆಸರು - ಅನಿಯಂತ್ರಿತ
   2. ಸಂಸ್ಥೆ - ಪ್ರಸ್ತುತ
   3. ಮಾನ್ಯತೆಯ ಅವಧಿ: ಗರಿಷ್ಠ 1 ವರ್ಷ
   4. ವ್ಯಾಪ್ತಿ — ಪ್ಯಾಕೇಜಿಂಗ್/ಓದು ಮತ್ತು ಬರೆಯಿರಿ
      

9. ರಚಿಸಿದ ಟೋಕನ್ ಅನ್ನು ನಕಲಿಸಿ — ಮಾದರಿ ವಿಂಡೋವನ್ನು ಮುಚ್ಚಿದ ನಂತರ ಮೌಲ್ಯವು ಲಭ್ಯವಿರುವುದಿಲ್ಲ.

10. GitLab ನಲ್ಲಿ ರೆಪೊಸಿಟರಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳಿಗೆ ಹೋಗಿ, CI/CD ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಆಯ್ಕೆಮಾಡಿ.
    

11. ವೇರಿಯೇಬಲ್ಸ್ ಬ್ಲಾಕ್ ಅನ್ನು ತೆರೆಯಿರಿ ಮತ್ತು ಹೊಸದನ್ನು ಸೇರಿಸಿ.

    1. ಹೆಸರು - ಸ್ಥಳಾವಕಾಶವಿಲ್ಲದ ಯಾವುದೇ (ಆಜ್ಞಾ ಶೆಲ್‌ನಲ್ಲಿ ಲಭ್ಯವಿರುತ್ತದೆ)
    2. ಮೌಲ್ಯ - ಪಾಯಿಂಟ್ 9 ರಿಂದ ಪ್ರವೇಶ ಟೋಕನ್
    3. ಮಾಸ್ಕ್ ವೇರಿಯೇಬಲ್ ಆಯ್ಕೆಮಾಡಿ
       

ಇದು ಪ್ರಾಥಮಿಕ ಸೆಟಪ್ ಅನ್ನು ಪೂರ್ಣಗೊಳಿಸುತ್ತದೆ.

ಸಂರಚನಾ ಚೌಕಟ್ಟನ್ನು ಸಿದ್ಧಪಡಿಸುವುದು

ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, GitLab ನಲ್ಲಿ CI/CD ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಬಳಸುವ ಫೈಲ್ .gitlab-ci.yml ರೆಪೊಸಿಟರಿಯ ಮೂಲದಿಂದ. ನೀವು ರೆಪೊಸಿಟರಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳಲ್ಲಿ ಈ ಫೈಲ್‌ಗೆ ಅನಿಯಂತ್ರಿತ ಮಾರ್ಗವನ್ನು ಹೊಂದಿಸಬಹುದು, ಆದರೆ ಈ ಸಂದರ್ಭದಲ್ಲಿ ಅದು ಅಗತ್ಯವಿಲ್ಲ.

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

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

image: mcr.microsoft.com/dotnet/core/sdk:3.1

ಈಗ, ನೀವು ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಿದಾಗ, ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಚಿತ್ರವನ್ನು ಮೈಕ್ರೋಸಾಫ್ಟ್ ಇಮೇಜ್ ಸ್ಟೋರ್‌ನಿಂದ ಡೌನ್‌ಲೋಡ್ ಮಾಡಲಾಗುತ್ತದೆ, ಇದರಲ್ಲಿ ಕಾನ್ಫಿಗರೇಶನ್‌ನಿಂದ ಎಲ್ಲಾ ಕಾರ್ಯಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ.

ಮುಂದಿನ ಹಂತವು ಸೇರಿಸುವುದು ಹಂತ's. ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, GitLab 5 ಹಂತಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ:

• .pre - ಎಲ್ಲಾ ಹಂತಗಳ ಮೊದಲು ನಡೆಸಲಾಗುತ್ತದೆ,
• .post - ಎಲ್ಲಾ ಹಂತಗಳ ನಂತರ ನಡೆಸಲಾಗುತ್ತದೆ,
• build - ನಂತರ ಮೊದಲನೆಯದು .pre ಹಂತ,
• test - ಎರಡನೇ ಹಂತ,
• deploy - ಮೂರನೇ ಹಂತ.

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

stages:
  - build
  - test
  - deploy

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

before_script:
  - $PSVersionTable.PSVersion
  - dotnet --version
  - nuget help | select-string Version

ಕಮಿಟ್‌ಗಳನ್ನು ಕಳುಹಿಸಿದಾಗ ಪೈಪ್‌ಲೈನ್ ಪ್ರಾರಂಭವಾಗುವಂತೆ ಕನಿಷ್ಠ ಒಂದು ಕಾರ್ಯವನ್ನು ಸೇರಿಸುವುದು ಮಾತ್ರ ಉಳಿದಿದೆ. ಇದೀಗ, ಪ್ರದರ್ಶನಕ್ಕಾಗಿ ಖಾಲಿ ಕಾರ್ಯವನ್ನು ಸೇರಿಸೋಣ:

dummy job:
  script:
    - echo ok

ನಾವು ಮೌಲ್ಯೀಕರಣವನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ, ಎಲ್ಲವೂ ಸರಿಯಾಗಿದೆ ಎಂಬ ಸಂದೇಶವನ್ನು ಪಡೆಯುತ್ತೇವೆ, ಬದ್ಧರಾಗುತ್ತೇವೆ, ತಳ್ಳುತ್ತೇವೆ, ಸೈಟ್‌ನಲ್ಲಿ ಫಲಿತಾಂಶಗಳನ್ನು ನೋಡುತ್ತೇವೆ... ಮತ್ತು ನಮಗೆ ಸ್ಕ್ರಿಪ್ಟ್ ದೋಷ ಬರುತ್ತದೆ - bash: .PSVersion: command not found. ಏನು?

ಎಲ್ಲವೂ ತಾರ್ಕಿಕವಾಗಿದೆ - ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ರನ್ನರ್‌ಗಳು (ಟಾಸ್ಕ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಜವಾಬ್ದಾರಿ ಮತ್ತು GitLab ನಿಂದ ಒದಗಿಸಲಾಗಿದೆ) ಬಳಸುತ್ತಾರೆ bash ಆಜ್ಞೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು. ಕಾರ್ಯ ವಿವರಣೆಯಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಪೈಪ್‌ಲೈನ್ ರನ್ನರ್ ಯಾವ ಟ್ಯಾಗ್‌ಗಳನ್ನು ಹೊಂದಿರಬೇಕು ಎಂಬುದನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ನಿರ್ದಿಷ್ಟಪಡಿಸುವ ಮೂಲಕ ನೀವು ಇದನ್ನು ಸರಿಪಡಿಸಬಹುದು:

dummy job on windows:
  script:
    - echo ok
  tags:
    - windows

ಅದ್ಭುತ! ಈಗ ಪೈಪ್‌ಲೈನ್ ಚಾಲನೆಯಲ್ಲಿದೆ.

ಗಮನವಿಟ್ಟು ಓದುಗನು ಸೂಚಿಸಿದ ಹಂತಗಳನ್ನು ಪುನರಾವರ್ತಿಸುತ್ತಾ, ಕಾರ್ಯವು ಹಂತ ಹಂತವಾಗಿ ಪೂರ್ಣಗೊಂಡಿರುವುದನ್ನು ಗಮನಿಸುತ್ತಾನೆ. test, ನಾವು ಹಂತವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸದಿದ್ದರೂ. ನೀವು ಊಹಿಸುವಂತೆ, test ಪೂರ್ವನಿಯೋಜಿತ ಹಂತವಾಗಿದೆ.

ಮೇಲೆ ವಿವರಿಸಿದ ಎಲ್ಲಾ ಕಾರ್ಯಗಳನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ಸಂರಚನಾ ಅಸ್ಥಿಪಂಜರವನ್ನು ರಚಿಸುವುದನ್ನು ಮುಂದುವರಿಸೋಣ:

build job:
  script:
    - echo "building..."
  tags:
    - windows
  stage: build

test and cover job:
  script:
    - echo "running tests and coverage analysis..."
  tags:
    - windows
  stage: test

pack and deploy job:
  script:
    - echo "packing and pushing to nuget..."
  tags:
    - windows
  stage: deploy

pages:
  script:
    - echo "creating docs..."
  tags:
    - windows
  stage: deploy

ನಮಗೆ ಸಿಕ್ಕ ಪೈಪ್‌ಲೈನ್ ವಿಶೇಷವಾಗಿ ಕ್ರಿಯಾತ್ಮಕವಾಗಿಲ್ಲದಿದ್ದರೂ ಸರಿಯಾಗಿತ್ತು.

ಟ್ರಿಗ್ಗರ್‌ಗಳನ್ನು ಹೊಂದಿಸಲಾಗುತ್ತಿದೆ

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

ಫಿಲ್ಟರ್‌ಗಳನ್ನು ಎರಡು ಸ್ವರೂಪಗಳಲ್ಲಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು: ಮಾತ್ರ/ಹೊರತುಪಡಿಸಿ и ನಿಯಮಗಳು. ಸಂಕ್ಷಿಪ್ತವಾಗಿ, only/except ಟ್ರಿಗ್ಗರ್‌ಗಳ ಮೂಲಕ ಫಿಲ್ಟರ್‌ಗಳನ್ನು ಹೊಂದಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ (merge_request, ಉದಾಹರಣೆಗೆ - ಪ್ರತಿ ಬಾರಿ ವಿಲೀನ ವಿನಂತಿಯನ್ನು ರಚಿಸಿದಾಗ ಮತ್ತು ಪ್ರತಿ ಬಾರಿ ವಿಲೀನ ವಿನಂತಿಯ ಮೂಲವಾಗಿರುವ ಶಾಖೆಗೆ ಕಮಿಟ್‌ಗಳನ್ನು ಕಳುಹಿಸಿದಾಗ ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕಾದ ಕಾರ್ಯವನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತದೆ) ಮತ್ತು ಶಾಖೆಯ ಹೆಸರುಗಳು (ನಿಯಮಿತ ಅಭಿವ್ಯಕ್ತಿಗಳನ್ನು ಬಳಸುವುದು ಸೇರಿದಂತೆ); rules ಹಿಂದಿನ ಕಾರ್ಯಗಳ ಯಶಸ್ಸನ್ನು ಅವಲಂಬಿಸಿ, ಷರತ್ತುಗಳ ಗುಂಪನ್ನು ಕಸ್ಟಮೈಸ್ ಮಾಡಲು ಮತ್ತು ಐಚ್ಛಿಕವಾಗಿ, ಕಾರ್ಯ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸ್ಥಿತಿಯನ್ನು ಬದಲಾಯಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ (when GitLab CI/CD ಯಲ್ಲಿ).

ವಿಲೀನ ವಿನಂತಿಗಳಿಗೆ ಮಾತ್ರ ಜೋಡಣೆ ಮತ್ತು ಪರೀಕ್ಷೆ, ಪ್ಯಾಕೇಜಿಂಗ್ ಮತ್ತು Azure DevOps ಗೆ ಕಳುಹಿಸುವುದು - ವಿಲೀನ ವಿನಂತಿಗಳು ಮತ್ತು ಮಾಸ್ಟರ್‌ಗೆ ತಳ್ಳುವಿಕೆಗಳು, ದಸ್ತಾವೇಜನ್ನು ಉತ್ಪಾದಿಸುವಿಕೆ - ಮಾಸ್ಟರ್‌ಗೆ ತಳ್ಳುವಿಕೆಗಳಿಗಾಗಿ ಅವಶ್ಯಕತೆಗಳ ಗುಂಪನ್ನು ನೆನಪಿಸಿಕೊಳ್ಳೋಣ.

ಮೊದಲಿಗೆ, ವಿಲೀನ ವಿನಂತಿ ಇದ್ದಾಗ ಮಾತ್ರ ಟ್ರಿಗ್ಗರ್ ಮಾಡಲು ನಿಯಮವನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ಕೋಡ್ ಬಿಲ್ಡ್ ಕಾರ್ಯವನ್ನು ಹೊಂದಿಸೋಣ:

build job:
  # snip
  only:
    - merge_request

ಈಗ ವಿಲೀನ ವಿನಂತಿಯನ್ನು ಪ್ರಚೋದಿಸಲು ಮತ್ತು ಮಾಸ್ಟರ್‌ಗೆ ಕಮಿಟ್‌ಗಳನ್ನು ಸೇರಿಸಲು ಪ್ಯಾಕಿಂಗ್ ಕಾರ್ಯವನ್ನು ಹೊಂದಿಸೋಣ:

pack and deploy job:
  # snip
  only:
    - merge_request
    - master

ನೀವು ನೋಡುವಂತೆ, ಎಲ್ಲವೂ ಸರಳ ಮತ್ತು ನೇರವಾಗಿರುತ್ತದೆ.

ನಿರ್ದಿಷ್ಟ ಗುರಿ ಅಥವಾ ಮೂಲ ಶಾಖೆಯೊಂದಿಗೆ ವಿಲೀನ ವಿನಂತಿಯನ್ನು ರಚಿಸಿದರೆ ಮಾತ್ರ ನೀವು ಕಾರ್ಯವನ್ನು ಪ್ರಾರಂಭಿಸಲು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು:

  rules:
    - if: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"

ಬಳಸಲು ಸಾಧ್ಯವಿರುವ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಇಲ್ಲಿ ಪಟ್ಟಿ ಮಾಡಲಾದ ಅಸ್ಥಿರಗಳುನಿಯಮಗಳು rules ನಿಯಮಗಳಿಗೆ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ only/except.

ಕಲಾಕೃತಿ ಸಂರಕ್ಷಣೆಯನ್ನು ಸ್ಥಾಪಿಸುವುದು

ಕಾರ್ಯವನ್ನು ನಿರ್ವಹಿಸುವ ಸಮಯದಲ್ಲಿ build job ನಂತರದ ಕಾರ್ಯಗಳಲ್ಲಿ ಮರುಬಳಕೆ ಮಾಡಬಹುದಾದ ಬಿಲ್ಡ್ ಆರ್ಟಿಫ್ಯಾಕ್ಟ್‌ಗಳನ್ನು ನಾವು ರಚಿಸಿದ್ದೇವೆ. ಇದನ್ನು ಮಾಡಲು, ನೀವು ಕಾರ್ಯ ಸಂರಚನೆಗೆ ಮಾರ್ಗಗಳನ್ನು ಸೇರಿಸಬೇಕು, ನಂತರದ ಕಾರ್ಯಗಳಲ್ಲಿ ನೀವು ಉಳಿಸಲು ಮತ್ತು ಮರುಬಳಕೆ ಮಾಡಲು ಅಗತ್ಯವಿರುವ ಫೈಲ್‌ಗಳನ್ನು ಕೀಲಿಯಲ್ಲಿ ಸೇರಿಸಬೇಕು. artifacts:

build job:
  # snip
  artifacts:
    paths:
      - path/to/build/artifacts
      - another/path
      - MyCoolLib.*/bin/Release/*

ಮಾರ್ಗಗಳು ವೈಲ್ಡ್‌ಕಾರ್ಡ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತವೆ, ಇದು ಖಂಡಿತವಾಗಿಯೂ ಅವುಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಲು ಸುಲಭಗೊಳಿಸುತ್ತದೆ.

ಒಂದು ಕಾರ್ಯವು ಕಲಾಕೃತಿಗಳನ್ನು ರಚಿಸಿದರೆ, ನಂತರದ ಪ್ರತಿಯೊಂದು ಕಾರ್ಯವು ಅವುಗಳನ್ನು ಪ್ರವೇಶಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ - ಅವು ಮೂಲ ಕಾರ್ಯದಿಂದ ಸಂಗ್ರಹಿಸಲಾದ ರೆಪೊಸಿಟರಿ ಮೂಲಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತೆ ಅದೇ ಮಾರ್ಗಗಳಲ್ಲಿ ನೆಲೆಗೊಂಡಿರುತ್ತವೆ. ಕಲಾಕೃತಿಗಳು ಸೈಟ್‌ನಲ್ಲಿ ಡೌನ್‌ಲೋಡ್ ಮಾಡಲು ಸಹ ಲಭ್ಯವಿದೆ.

ಈಗ ನಾವು ಸಿದ್ಧ (ಮತ್ತು ಪರೀಕ್ಷಿಸಲ್ಪಟ್ಟ) ಸಂರಚನಾ ಚೌಕಟ್ಟನ್ನು ಹೊಂದಿದ್ದೇವೆ, ನಾವು ಕಾರ್ಯಗಳಿಗಾಗಿ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಬರೆಯಲು ಮುಂದುವರಿಯಬಹುದು.

ನಾವು ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಬರೆಯುತ್ತೇವೆ

ಬಹುಶಃ, ಒಂದು ಕಾಲದಲ್ಲಿ, ದೂರದ ನಕ್ಷತ್ರಪುಂಜದಲ್ಲಿ, ಕಮಾಂಡ್ ಲೈನ್‌ನಿಂದ ಯೋಜನೆಗಳನ್ನು (.net ನಲ್ಲಿರುವವುಗಳನ್ನು ಒಳಗೊಂಡಂತೆ) ನಿರ್ಮಿಸುವುದು ಕಷ್ಟಕರವಾಗಿತ್ತು. ಈಗ, ನೀವು 3 ಆಜ್ಞೆಗಳಲ್ಲಿ ಯೋಜನೆಯನ್ನು ನಿರ್ಮಿಸಬಹುದು, ಪರೀಕ್ಷಿಸಬಹುದು ಮತ್ತು ಪ್ರಕಟಿಸಬಹುದು:

dotnet build
dotnet test
dotnet pack

ಸ್ವಾಭಾವಿಕವಾಗಿ, ಕೆಲವು ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳಿವೆ, ಇದರಿಂದಾಗಿ ನಾವು ಆಜ್ಞೆಗಳನ್ನು ಸ್ವಲ್ಪ ಸಂಕೀರ್ಣಗೊಳಿಸುತ್ತೇವೆ.

1. ನಮಗೆ ಡೀಬಗ್ ಬಿಲ್ಡ್ ಅಲ್ಲ, ಬಿಡುಗಡೆ ಬಿಲ್ಡ್ ಬೇಕು, ಆದ್ದರಿಂದ ನಾವು ಪ್ರತಿ ಆಜ್ಞೆಗೆ ಸೇರಿಸುತ್ತೇವೆ -c Release
2. ಪರೀಕ್ಷಿಸುವಾಗ, ನಾವು ಕೋಡ್ ಕವರೇಜ್ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು ಬಯಸುತ್ತೇವೆ, ಆದ್ದರಿಂದ ನಾವು ಪರೀಕ್ಷಾ ಗ್ರಂಥಾಲಯಗಳಿಗೆ ಕವರೇಜ್ ವಿಶ್ಲೇಷಕವನ್ನು ಸಂಪರ್ಕಿಸಬೇಕಾಗುತ್ತದೆ:
   1. ಎಲ್ಲಾ ಪರೀಕ್ಷಾ ಗ್ರಂಥಾಲಯಗಳು ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಒಳಗೊಂಡಿರಬೇಕು coverlet.msbuild: dotnet add package coverlet.msbuild ಯೋಜನೆಯ ಫೋಲ್ಡರ್ನಿಂದ
   2. ಪರೀಕ್ಷಾ ಉಡಾವಣಾ ಆಜ್ಞೆಗೆ ಸೇರಿಸೋಣ /p:CollectCoverage=true
   3. ಕವರೇಜ್ ಫಲಿತಾಂಶಗಳನ್ನು ಪಡೆಯಲು ನಾವು ಪರೀಕ್ಷಾ ಕಾರ್ಯ ಸಂರಚನೆಗೆ ಒಂದು ಕೀಲಿಯನ್ನು ಸೇರಿಸುತ್ತೇವೆ (ಕೆಳಗೆ ನೋಡಿ)
3. ಕೋಡ್ ಅನ್ನು ನುಜೆಟ್ ಪ್ಯಾಕೇಜ್‌ಗಳಲ್ಲಿ ಪ್ಯಾಕೇಜಿಂಗ್ ಮಾಡುವಾಗ, ನಾವು ಪ್ಯಾಕೇಜ್‌ಗಳಿಗಾಗಿ ಔಟ್‌ಪುಟ್ ಡೈರೆಕ್ಟರಿಯನ್ನು ಹೊಂದಿಸುತ್ತೇವೆ: -o .

ಕೋಡ್ ಕವರೇಜ್ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲಾಗುತ್ತಿದೆ

ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸಿದ ನಂತರ, ಕವರ್ಲೆಟ್ ಔಟ್‌ಪುಟ್‌ಗಳು ಕನ್ಸೋಲ್‌ಗೆ ಅಂಕಿಅಂಶಗಳನ್ನು ಚಲಾಯಿಸುತ್ತವೆ:

Calculating coverage result...
  Generating report 'C:Usersxxxsourcereposmy-projectmyProject.testscoverage.json'

+-------------+--------+--------+--------+
| Module      | Line   | Branch | Method |
+-------------+--------+--------+--------+
| project 1   | 83,24% | 66,66% | 92,1%  |
+-------------+--------+--------+--------+
| project 2   | 87,5%  | 50%    | 100%   |
+-------------+--------+--------+--------+
| project 3   | 100%   | 83,33% | 100%   |
+-------------+--------+--------+--------+

+---------+--------+--------+--------+
|         | Line   | Branch | Method |
+---------+--------+--------+--------+
| Total   | 84,27% | 65,76% | 92,94% |
+---------+--------+--------+--------+
| Average | 90,24% | 66,66% | 97,36% |
+---------+--------+--------+--------+

ಅಂಕಿಅಂಶಗಳನ್ನು ಪಡೆಯಲು ನಿಯಮಿತ ಅಭಿವ್ಯಕ್ತಿಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಲು GitLab ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ನಂತರ ಅದನ್ನು ಬ್ಯಾಡ್ಜ್ ಆಗಿ ಪಡೆಯಬಹುದು. ನಿಯಮಿತ ಅಭಿವ್ಯಕ್ತಿಯನ್ನು ಕಾರ್ಯ ಸೆಟ್ಟಿಂಗ್‌ಗಳಲ್ಲಿ ಕೀಲಿಯೊಂದಿಗೆ ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗುತ್ತದೆ coverage; ಅಭಿವ್ಯಕ್ತಿಯು ಕ್ಯಾಪ್ಚರ್ ಗುಂಪನ್ನು ಹೊಂದಿರಬೇಕು, ಅದರ ಮೌಲ್ಯವನ್ನು ಬ್ಯಾಡ್ಜ್‌ಗೆ ರವಾನಿಸಲಾಗುತ್ತದೆ:

test and cover job:
  # snip
  coverage: /|s*Totals*|s*(d+[,.]d+%)/

ಇಲ್ಲಿ ನಾವು ಒಟ್ಟು ವ್ಯಾಪ್ತಿಯೊಂದಿಗೆ ಸಾಲಿನ ಅಂಕಿಅಂಶಗಳನ್ನು ಸಾಲುಗಳ ಮೂಲಕ ಪಡೆಯುತ್ತೇವೆ.

ನಾವು ಪ್ಯಾಕೇಜುಗಳು ಮತ್ತು ದಸ್ತಾವೇಜನ್ನು ಪ್ರಕಟಿಸುತ್ತೇವೆ.

ಪೈಪ್‌ಲೈನ್‌ನ ಕೊನೆಯ ಹಂತಕ್ಕೆ ನಾವು ಎರಡೂ ಕ್ರಮಗಳನ್ನು ನಿಗದಿಪಡಿಸಿದ್ದೇವೆ - ಜೋಡಣೆ ಮತ್ತು ಪರೀಕ್ಷೆಯು ಮುಗಿದ ನಂತರ, ನಾವು ನಮ್ಮ ಬೆಳವಣಿಗೆಗಳನ್ನು ಪ್ರಪಂಚದೊಂದಿಗೆ ಹಂಚಿಕೊಳ್ಳಬಹುದು.

ಪ್ಯಾಕೇಜ್ ಮೂಲಕ್ಕೆ ಪ್ರಕಟಿಸುವುದನ್ನು ನೋಡುವ ಮೂಲಕ ಪ್ರಾರಂಭಿಸೋಣ:

1. ಯೋಜನೆಯು ನ್ಯೂಜೆಟ್ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಅನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ (nuget.config), ಹೊಸದನ್ನು ರಚಿಸೋಣ: dotnet new nugetconfig

   ಯಾವುದಕ್ಕಾಗಿ: ಚಿತ್ರವು ಜಾಗತಿಕ (ಬಳಕೆದಾರ ಮತ್ತು ಯಂತ್ರ) ಸಂರಚನೆಗಳಿಗೆ ಬರೆಯಲು ಪ್ರವೇಶವನ್ನು ನಿರಾಕರಿಸಿರಬಹುದು. ದೋಷಗಳನ್ನು ತಪ್ಪಿಸಲು, ಹೊಸ ಸ್ಥಳೀಯ ಸಂರಚನೆಯನ್ನು ರಚಿಸಿ ಅದರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡೋಣ.

2. ಸ್ಥಳೀಯ ಸಂರಚನೆಗೆ ಹೊಸ ಪ್ಯಾಕೇಜ್ ಮೂಲವನ್ನು ಸೇರಿಸೋಣ: nuget sources add -name <name> -source <url> -username <organization> -password <gitlab variable> -configfile nuget.config -StorePasswordInClearText
   1. name — ಮೂಲದ ಸ್ಥಳೀಯ ಹೆಸರು, ಮುಖ್ಯವಲ್ಲ
   2. url — “ಖಾತೆಗಳನ್ನು ಸಿದ್ಧಪಡಿಸುವುದು” ಹಂತ, ಐಟಂ 6 ರಿಂದ ಮೂಲದ URL
   3. organization — Azure DevOps ನಲ್ಲಿ ಸಂಸ್ಥೆಯ ಹೆಸರು
   4. gitlab variable — GitLab ಗೆ ಸೇರಿಸಲಾದ ಪ್ರವೇಶ ಟೋಕನ್‌ನೊಂದಿಗೆ ವೇರಿಯೇಬಲ್‌ನ ಹೆಸರು ("ಖಾತೆಗಳನ್ನು ಸಿದ್ಧಪಡಿಸುವುದು", ಪುಟ 11). ಸ್ವಾಭಾವಿಕವಾಗಿ, ಸ್ವರೂಪದಲ್ಲಿ $variableName
   5. -StorePasswordInClearText - ಪ್ರವೇಶ ನಿರಾಕರಿಸಿದ ದೋಷವನ್ನು ಬೈಪಾಸ್ ಮಾಡಲು ಹ್ಯಾಕ್ ಮಾಡಿ (ಈ ಕುಂಟೆಯ ಮೇಲೆ ಹೆಜ್ಜೆ ಹಾಕುವ ಮೊದಲಿಗ ನಾನಲ್ಲ.)
   6. ದೋಷಗಳಿದ್ದಲ್ಲಿ ಸೇರಿಸಲು ಇದು ಉಪಯುಕ್ತವಾಗಬಹುದು -verbosity detailed
3. ನಾವು ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಮೂಲಕ್ಕೆ ಕಳುಹಿಸುತ್ತೇವೆ: nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
   1. ನಾವು ಪ್ರಸ್ತುತ ಡೈರೆಕ್ಟರಿಯಿಂದ ಎಲ್ಲಾ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಕಳುಹಿಸುತ್ತೇವೆ, ಆದ್ದರಿಂದ *.nupkg.
   2. name — ಮೇಲಿನ ಹಂತದಿಂದ.
   3. key — ಯಾವುದೇ ಸ್ಟ್ರಿಂಗ್. Azure DevOps ನಲ್ಲಿ, ಕನೆಕ್ಟ್ ಟು ಫೀಡ್ ವಿಂಡೋ ಯಾವಾಗಲೂ ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ಉದಾಹರಣೆಯಾಗಿ ತೋರಿಸುತ್ತದೆ az.
   4. -skipduplicate - ಈ ಕೀಲಿಯಿಲ್ಲದೆ ನೀವು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಕಳುಹಿಸಲು ಪ್ರಯತ್ನಿಸಿದರೆ, ಮೂಲವು ದೋಷವನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ 409 Conflict; ಕೀಲಿಯೊಂದಿಗೆ ಕಳುಹಿಸುವುದನ್ನು ಬಿಟ್ಟುಬಿಡಲಾಗುತ್ತದೆ.

ಈಗ ದಸ್ತಾವೇಜನ್ನು ರಚನೆಯನ್ನು ಹೊಂದಿಸೋಣ:

1. ಮೊದಲು, ರೆಪೊಸಿಟರಿಯಲ್ಲಿ, ಮಾಸ್ಟರ್ ಶಾಖೆಯಲ್ಲಿ, docfx ಯೋಜನೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿ. ಇದನ್ನು ಮಾಡಲು, ನೀವು ರೂಟ್‌ನಿಂದ ಆಜ್ಞೆಯನ್ನು ಚಲಾಯಿಸಬೇಕು. docfx init ಮತ್ತು ದಸ್ತಾವೇಜನ್ನು ಜೋಡಿಸಲು ಪ್ರಮುಖ ನಿಯತಾಂಕಗಳನ್ನು ಸಂವಾದಾತ್ಮಕವಾಗಿ ಹೊಂದಿಸಿ. ಕನಿಷ್ಠ ಯೋಜನೆಯ ಸೆಟಪ್‌ನ ವಿವರವಾದ ವಿವರಣೆ ಇಲ್ಲಿ.
   1. ಹೊಂದಿಸುವಾಗ, ಔಟ್‌ಪುಟ್ ಡೈರೆಕ್ಟರಿಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುವುದು ಮುಖ್ಯ. ..public — GitLab ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ರೆಪೊಸಿಟರಿ ರೂಟ್‌ನಲ್ಲಿರುವ ಸಾರ್ವಜನಿಕ ಫೋಲ್ಡರ್‌ನ ವಿಷಯಗಳನ್ನು ಪುಟಗಳಿಗೆ ಮೂಲವಾಗಿ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಪ್ರಾಜೆಕ್ಟ್ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ನೆಸ್ಟೆಡ್ ಫೋಲ್ಡರ್‌ನಲ್ಲಿ ಇರುವುದರಿಂದ, ನಾವು ಪಥಕ್ಕೆ ಒಂದು ಹಂತದ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಸೇರಿಸುತ್ತೇವೆ.
2. ಬದಲಾವಣೆಗಳನ್ನು GitLab ಗೆ ಕಳುಹಿಸೋಣ.
3. ಪೈಪ್‌ಲೈನ್ ಕಾನ್ಫಿಗರೇಶನ್‌ಗೆ ಒಂದು ಕಾರ್ಯವನ್ನು ಸೇರಿಸೋಣ. pages (GitLab ಪುಟಗಳ ಸೈಟ್ ಪ್ರಕಟಣೆ ಕಾರ್ಯಗಳಿಗಾಗಿ ಕಾಯ್ದಿರಿಸಿದ ಪದ):
   1. ಸ್ಕ್ರಿಪ್ಟ್:
      1. nuget install docfx.console -version 2.51.0 — docfx ಅನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ; ಪ್ಯಾಕೇಜ್ ಅನುಸ್ಥಾಪನಾ ಮಾರ್ಗಗಳು ಸರಿಯಾಗಿವೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಆವೃತ್ತಿಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗಿದೆ.
      2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json - ನಾವು ದಾಖಲೆಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ
   2. ಕಲಾಕೃತಿಗಳ ನೋಡ್:

pages:
  # snip
  artifacts:
    paths:
      - public

docfx ಬಗ್ಗೆ ಒಂದು ಭಾವಗೀತಾತ್ಮಕ ವಿಷಯಾಂತರ

ಹಿಂದೆ, ಒಂದು ಯೋಜನೆಯನ್ನು ಹೊಂದಿಸುವಾಗ, ನಾನು ದಸ್ತಾವೇಜನ್ನುಗಾಗಿ ಮೂಲ ಕೋಡ್ ಅನ್ನು ಪರಿಹಾರ ಫೈಲ್ ಆಗಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದೆ. ಮುಖ್ಯ ಅನಾನುಕೂಲವೆಂದರೆ ಪರೀಕ್ಷಾ ಯೋಜನೆಗಳಿಗೆ ದಸ್ತಾವೇಜನ್ನು ಸಹ ರಚಿಸಲಾಗಿದೆ. ಇದು ಅಗತ್ಯವಿಲ್ಲದಿದ್ದರೆ, ನೀವು ನೋಡ್‌ಗೆ ಅಂತಹ ಮೌಲ್ಯವನ್ನು ಹೊಂದಿಸಬಹುದು. metadata.src:

{
  "metadata": [
    {
      "src": [
        {
          "src": "../",
          "files": [
            "**/*.csproj"
          ],
          "exclude":[
            "*.tests*/**"
          ]
        }
      ],
      // --- snip ---
    },
    // --- snip ---
  ],
  // --- snip ---
}

1. metadata.src.src: "../" - ನಾವು ಸ್ಥಳಕ್ಕೆ ಹೋಲಿಸಿದರೆ ಒಂದು ಹಂತ ಮೇಲಕ್ಕೆ ಹೋಗುತ್ತೇವೆ docfx.json, ಏಕೆಂದರೆ ಡೈರೆಕ್ಟರಿ ಟ್ರೀ ಅನ್ನು ಹುಡುಕುವುದು ಪ್ಯಾಟರ್ನ್‌ಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ.
2. metadata.src.files: ["**/*.csproj"] — ಜಾಗತಿಕ ಮಾದರಿ, ನಾವು ಎಲ್ಲಾ ಡೈರೆಕ್ಟರಿಗಳಿಂದ ಎಲ್ಲಾ C# ಯೋಜನೆಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ.
3. metadata.src.exclude: ["*.tests*/**"] — ಜಾಗತಿಕ ಮಾದರಿ, ಫೋಲ್ಡರ್‌ಗಳಿಂದ ಎಲ್ಲವನ್ನೂ ಹೊರಗಿಡಿ .tests ಶೀರ್ಷಿಕೆಯಲ್ಲಿ

ಒಟ್ಟು ಮೊತ್ತ

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

ಅಂತಿಮ .gitlab-ci.yml

image: mcr.microsoft.com/dotnet/core/sdk:3.1

before_script:
  - $PSVersionTable.PSVersion
  - dotnet --version
  - nuget help | select-string Version

stages:
  - build
  - test
  - deploy

build job:
  stage: build
  script:
    - dotnet build -c Release
  tags:
    - windows
  only:
    - merge_requests
    - master
  artifacts:
    paths:
      - your/path/to/binaries

test and cover job:
  stage: test
  tags:
    - windows
  script:
    - dotnet test -c Release /p:CollectCoverage=true
  coverage: /|s*Totals*|s*(d+[,.]d+%)/
  only:
    - merge_requests
    - master

pack and deploy job:
  stage: deploy
  tags:
    - windows
  script:
    - dotnet pack -c Release -o .
    - dotnet new nugetconfig
    - nuget sources add -name feedName -source https://pkgs.dev.azure.com/your-organization/_packaging/your-feed/nuget/v3/index.json -username your-organization -password $nugetFeedToken -configfile nuget.config -StorePasswordInClearText
    - nuget push -source feedName -skipduplicate -apikey az *.nupkg
  only:
    - master

pages:
  tags:
    - windows
  stage: deploy
  script:
    - nuget install docfx.console -version 2.51.0
    - $env:path = "$env:path;$($(get-location).Path)"
    - .docfx.console.2.51.0toolsdocfx.exe .docfxdocfx.json
  artifacts:
    paths:
      - public
  only:
    - master

ಬ್ಯಾಡ್ಜ್‌ಗಳ ಕುರಿತು ಮಾತನಾಡುತ್ತಾ

ಎಲ್ಲಾ ನಂತರ, ಇದೆಲ್ಲವೂ ಅವರ ಸಲುವಾಗಿಯೇ ಆಗಿತ್ತು!

Gtntral ಪೈಪ್‌ಲೈನ್‌ಗಳ ಬ್ಲಾಕ್‌ನಲ್ಲಿರುವ CI/CD ಸೆಟ್ಟಿಂಗ್‌ಗಳಲ್ಲಿ GitLab ನಲ್ಲಿ ಪೈಪ್‌ಲೈನ್ ಸ್ಥಿತಿ ಮತ್ತು ಕೋಡ್ ಕವರೇಜ್ ಬ್ಯಾಡ್ಜ್‌ಗಳು ಲಭ್ಯವಿದೆ:

ನಾನು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿರುವ ದಸ್ತಾವೇಜನ್ನು ಲಿಂಕ್‌ನೊಂದಿಗೆ ಬ್ಯಾಡ್ಜ್ ಅನ್ನು ರಚಿಸಿದ್ದೇನೆ. ಶೀಲ್ಡ್ಸ್.ಐಒ — ಅಲ್ಲಿ ಎಲ್ಲವೂ ತುಂಬಾ ಸರಳವಾಗಿದೆ, ನೀವು ನಿಮ್ಮ ಸ್ವಂತ ಬ್ಯಾಡ್ಜ್ ಅನ್ನು ರಚಿಸಬಹುದು ಮತ್ತು ವಿನಂತಿಯನ್ನು ಬಳಸಿಕೊಂಡು ಅದನ್ನು ಸ್ವೀಕರಿಸಬಹುದು.

![Пример с Shields.io](https://img.shields.io/badge/custom-badge-blue)

Azure DevOps ಆರ್ಟಿಫ್ಯಾಕ್ಟ್‌ಗಳು ಪ್ರಸ್ತುತ ಆವೃತ್ತಿಯನ್ನು ಸೂಚಿಸುವ ಪ್ಯಾಕೇಜ್‌ಗಳಿಗೆ ಬ್ಯಾಡ್ಜ್‌ಗಳನ್ನು ರಚಿಸಲು ಸಹ ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಇದನ್ನು ಮಾಡಲು, Azure DevOps ಸೈಟ್‌ನಲ್ಲಿರುವ ಮೂಲದಲ್ಲಿ, ಆಯ್ಕೆಮಾಡಿದ ಪ್ಯಾಕೇಜ್‌ಗಾಗಿ ಬ್ಯಾಡ್ಜ್ ಅನ್ನು ರಚಿಸಿ ಕ್ಲಿಕ್ ಮಾಡಿ ಮತ್ತು ಮಾರ್ಕ್‌ಡೌನ್ ಮಾರ್ಕ್‌ಅಪ್ ಅನ್ನು ನಕಲಿಸಿ:

ಸೌಂದರ್ಯವನ್ನು ಸೇರಿಸುವುದು

ನಾವು ಸಾಮಾನ್ಯ ಸಂರಚನಾ ತುಣುಕುಗಳನ್ನು ಹೈಲೈಟ್ ಮಾಡುತ್ತೇವೆ.

ಸಂರಚನೆಯನ್ನು ಬರೆಯುವಾಗ ಮತ್ತು ದಸ್ತಾವೇಜನ್ನು ಹುಡುಕುವಾಗ, ನಾನು YAML ನ ಆಸಕ್ತಿದಾಯಕ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಕಂಡೆ - ತುಣುಕು ಮರುಬಳಕೆ.

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

.common_tags: &common_tags
  tags:
    - windows
.common_only: &common_only
  only:
    - merge_requests
    - master

ಮತ್ತು ಈಗ ಕಾರ್ಯ ವಿವರಣೆಯಲ್ಲಿ ನಾವು ಹಿಂದೆ ಘೋಷಿಸಿದ ತುಣುಕನ್ನು ಸೇರಿಸಬಹುದು:

build job:
  <<: *common_tags
  <<: *common_only

ಒಂದು ಕಾರ್ಯವೆಂದು ಅರ್ಥೈಸಿಕೊಳ್ಳುವುದನ್ನು ತಪ್ಪಿಸಲು ತುಣುಕುಗಳ ಹೆಸರುಗಳು ಪೂರ್ಣವಿರಾಮ ಚಿಹ್ನೆಯಿಂದ ಪ್ರಾರಂಭವಾಗಬೇಕು.

ಪ್ಯಾಕೇಜ್ ಆವೃತ್ತಿ ಮಾಡುವಿಕೆ

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

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

ಒಂದು ಕಮಿಟ್ ಸಂದೇಶವು ಈ ರೀತಿಯ ಸಾಲನ್ನು ಹೊಂದಿದ್ದರೆ ಅದನ್ನು ಒಪ್ಪಿಕೊಳ್ಳೋಣ release (v./ver./version) <version number> (rev./revision <revision>)?, ನಂತರ ನಾವು ಈ ಸಾಲಿನಿಂದ ಪ್ಯಾಕೇಜ್ ಆವೃತ್ತಿಯನ್ನು ತೆಗೆದುಕೊಂಡು, ಅದಕ್ಕೆ ಪ್ರಸ್ತುತ ದಿನಾಂಕವನ್ನು ಸೇರಿಸಿ ಮತ್ತು ಅದನ್ನು ಆಜ್ಞೆಗೆ ಆರ್ಗ್ಯುಮೆಂಟ್ ಆಗಿ ರವಾನಿಸುತ್ತೇವೆ. dotnet pack. ಸಾಲಿನ ಅನುಪಸ್ಥಿತಿಯಲ್ಲಿ, ನಾವು ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಜೋಡಿಸುವುದಿಲ್ಲ.

ಕೆಳಗಿನ ಸ್ಕ್ರಿಪ್ಟ್ ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ:

# регулярное выражение для поиска строки с версией
$rx = "releases+(v.?|ver.?|version)s*(?<maj>d+)(?<min>.d+)?(?<rel>.d+)?s*((rev.?|revision)?s+(?<rev>[a-zA-Z0-9-_]+))?"
# ищем строку в сообщении коммита, передаваемом в одной из предопределяемых GitLab'ом переменных
$found = $env:CI_COMMIT_MESSAGE -match $rx
# совпадений нет - выходим
if (!$found) { Write-Output "no release info found, aborting"; exit }
# извлекаем мажорную и минорную версии
$maj = $matches['maj']
$min = $matches['min']
# если строка содержит номер релиза - используем его, иначе - текущий год
if ($matches.ContainsKey('rel')) { $rel = $matches['rel'] } else { $rel = ".$(get-date -format "yyyy")" }
# в качестве номера сборки - текущие месяц и день
$bld = $(get-date -format "MMdd")
# если есть данные по пререлизной версии - включаем их в версию
if ($matches.ContainsKey('rev')) { $rev = "-$($matches['rev'])" } else { $rev = '' }
# собираем единую строку версии
$version = "$maj$min$rel.$bld$rev"
# собираем пакеты
dotnet pack -c Release -o . /p:Version=$version

ಕಾರ್ಯಕ್ಕೆ ಸ್ಕ್ರಿಪ್ಟ್ ಸೇರಿಸಿ pack and deploy job ಮತ್ತು ನಾವು ಕಮಿಟ್ ಸಂದೇಶದಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ಸಾಲಿನ ಉಪಸ್ಥಿತಿಯಲ್ಲಿ ಪ್ಯಾಕೇಜ್‌ಗಳ ಜೋಡಣೆಯನ್ನು ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಗಮನಿಸುತ್ತೇವೆ.

ಒಟ್ಟು

ಕಾನ್ಫಿಗರೇಶನ್ ಬರೆಯಲು, ಸ್ಥಳೀಯ ಪವರ್‌ಶೆಲ್‌ನಲ್ಲಿ ಡೀಬಗ್ ಮಾಡಲು ಮತ್ತು ಬಹುಶಃ ಒಂದೆರಡು ವಿಫಲ ಉಡಾವಣೆಗಳನ್ನು ಮಾಡಲು ಸುಮಾರು ಅರ್ಧ ಗಂಟೆಯಿಂದ ಒಂದು ಗಂಟೆಯವರೆಗೆ ಕಳೆದ ನಂತರ, ದಿನನಿತ್ಯದ ಕಾರ್ಯಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ನಮಗೆ ಸರಳವಾದ ಸಂರಚನೆ ಸಿಕ್ಕಿತು.

ಸಹಜವಾಗಿ, GitLab CI/CD ಈ ಮಾರ್ಗದರ್ಶಿಯನ್ನು ಓದಿದ ನಂತರ ತೋರುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ವಿಸ್ತಾರವಾಗಿದೆ ಮತ್ತು ಬಹುಮುಖಿಯಾಗಿದೆ - ಇದು ಸಂಪೂರ್ಣವಾಗಿ ನಿಜವಲ್ಲ.ಸಹ ಇದೆ ಆಟೋ ಡೆವೊಪ್ಸ್ ಎಂದರೆಅನುಮತಿಸುತ್ತದೆ

ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪತ್ತೆಹಚ್ಚಿ, ನಿರ್ಮಿಸಿ, ಪರೀಕ್ಷಿಸಿ, ನಿಯೋಜಿಸಿ ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ

ಪುಲುಮಿ ಮತ್ತು ಸ್ವಯಂಚಾಲಿತ ಗುರಿ ಪರಿಸರ ಪತ್ತೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಅಜೂರ್‌ಗೆ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿಯೋಜಿಸಲು ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುವುದು ಈಗ ಯೋಜನೆಗಳಾಗಿದ್ದು, ಇದನ್ನು ಮುಂದಿನ ಲೇಖನದಲ್ಲಿ ಚರ್ಚಿಸಲಾಗುವುದು.

ಮೂಲ: www.habr.com