(ਲਗਭਗ) ਪੂਰਨ ਸ਼ੁਰੂਆਤ ਕਰਨ ਵਾਲੇ ਲਈ GitLab ਵਿੱਚ CI/CD ਲਈ ਇੱਕ ਗਾਈਡ

ਜਾਂ ਆਸਾਨ ਕੋਡਿੰਗ ਦੀ ਇੱਕ ਸ਼ਾਮ ਵਿੱਚ ਆਪਣੇ ਪ੍ਰੋਜੈਕਟ ਲਈ ਸੁੰਦਰ ਬੈਜ ਕਿਵੇਂ ਪ੍ਰਾਪਤ ਕਰੀਏ

ਸੰਭਵ ਤੌਰ 'ਤੇ, ਹਰੇਕ ਡਿਵੈਲਪਰ ਜਿਸ ਕੋਲ ਕਿਸੇ ਸਮੇਂ ਘੱਟੋ ਘੱਟ ਇੱਕ ਪਾਲਤੂ ਪ੍ਰੋਜੈਕਟ ਹੈ, ਨੂੰ ਸਥਿਤੀਆਂ, ਕੋਡ ਕਵਰੇਜ, ਨਗੇਟ ਵਿੱਚ ਪੈਕੇਜ ਸੰਸਕਰਣਾਂ ਦੇ ਨਾਲ ਸੁੰਦਰ ਬੈਜਾਂ ਬਾਰੇ ਖੁਜਲੀ ਹੁੰਦੀ ਹੈ ... ਅਤੇ ਇਸ ਖਾਰਸ਼ ਨੇ ਮੈਨੂੰ ਇਹ ਲੇਖ ਲਿਖਣ ਲਈ ਅਗਵਾਈ ਕੀਤੀ. ਇਸਨੂੰ ਲਿਖਣ ਦੀ ਤਿਆਰੀ ਵਿੱਚ, ਮੈਨੂੰ ਇਹ ਸੁੰਦਰਤਾ ਮੇਰੇ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਮਿਲੀ:

ਇਹ ਲੇਖ ਤੁਹਾਨੂੰ GitLab ਵਿੱਚ ਇੱਕ .Net ਕੋਰ ਕਲਾਸ ਲਾਇਬ੍ਰੇਰੀ ਪ੍ਰੋਜੈਕਟ ਲਈ ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਅਤੇ ਡਿਲੀਵਰੀ ਦੇ ਬੁਨਿਆਦੀ ਸੈਟਅਪ, GitLab ਪੰਨਿਆਂ 'ਤੇ ਦਸਤਾਵੇਜ਼ ਪ੍ਰਕਾਸ਼ਤ ਕਰਨ, ਅਤੇ Azure DevOps ਵਿੱਚ ਇੱਕ ਨਿੱਜੀ ਫੀਡ ਵਿੱਚ ਬਿਲਟ ਪੈਕੇਜਾਂ ਨੂੰ ਧੱਕਣ ਦੇ ਬੁਨਿਆਦੀ ਸੈਟਅਪ ਬਾਰੇ ਦੱਸੇਗਾ।

VS ਕੋਡ ਨੂੰ ਐਕਸਟੈਂਸ਼ਨ ਦੇ ਨਾਲ ਵਿਕਾਸ ਵਾਤਾਵਰਣ ਵਜੋਂ ਵਰਤਿਆ ਗਿਆ ਸੀ GitLab ਵਰਕਫਲੋ (ਡਿਵੈਲਪਮੈਂਟ ਵਾਤਾਵਰਣ ਤੋਂ ਸਿੱਧੇ ਸੈਟਿੰਗਾਂ ਫਾਈਲ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਨ ਲਈ)।

ਸੰਖੇਪ ਜਾਣ ਪਛਾਣ

ਸੀਡੀ - ਕੀ ਇਹ ਉਦੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਹੁਣੇ ਧੱਕਾ ਕੀਤਾ ਹੈ, ਅਤੇ ਸਭ ਕੁਝ ਪਹਿਲਾਂ ਹੀ ਕਲਾਇੰਟ 'ਤੇ ਡਿੱਗ ਗਿਆ ਹੈ?

CI/CD ਕੀ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਇਸਦੀ ਲੋੜ ਕਿਉਂ ਹੈ - ਤੁਸੀਂ ਇਸਨੂੰ ਆਸਾਨੀ ਨਾਲ ਗੂਗਲ ਕਰ ਸਕਦੇ ਹੋ। GitLab ਵਿੱਚ ਪਾਈਪਲਾਈਨਾਂ ਦੀ ਸੰਰਚਨਾ ਕਰਨ ਬਾਰੇ ਪੂਰੇ ਦਸਤਾਵੇਜ਼ ਲੱਭੋ ਵੀ ਆਸਾਨ. ਇੱਥੇ ਮੈਂ ਸੰਖੇਪ ਵਿੱਚ ਅਤੇ, ਜੇ ਸੰਭਵ ਹੋਵੇ, ਬਿਨਾਂ ਕਿਸੇ ਕਮੀਆਂ ਦੇ ਇੱਕ ਪੰਛੀ ਦੀ ਅੱਖ ਦੇ ਦ੍ਰਿਸ਼ ਤੋਂ ਸਿਸਟਮ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦਾ ਵਰਣਨ ਕਰਾਂਗਾ:

• ਡਿਵੈਲਪਰ ਰਿਪੋਜ਼ਟਰੀ ਨੂੰ ਇੱਕ ਵਚਨਬੱਧਤਾ ਭੇਜਦਾ ਹੈ, ਸਾਈਟ ਦੁਆਰਾ ਇੱਕ ਅਭੇਦ ਬੇਨਤੀ ਬਣਾਉਂਦਾ ਹੈ, ਜਾਂ ਕਿਸੇ ਹੋਰ ਤਰੀਕੇ ਨਾਲ, ਸਪੱਸ਼ਟ ਜਾਂ ਅਪ੍ਰਤੱਖ ਤੌਰ 'ਤੇ ਪਾਈਪਲਾਈਨ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ,
• ਸਾਰੇ ਕਾਰਜ ਸੰਰਚਨਾ ਤੋਂ ਚੁਣੇ ਗਏ ਹਨ, ਜਿਸ ਦੀਆਂ ਸ਼ਰਤਾਂ ਉਹਨਾਂ ਨੂੰ ਦਿੱਤੇ ਸੰਦਰਭ ਵਿੱਚ ਲਾਂਚ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀਆਂ ਹਨ,
• ਕਾਰਜ ਉਹਨਾਂ ਦੇ ਪੜਾਵਾਂ ਦੇ ਅਨੁਸਾਰ ਆਯੋਜਿਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ,
• ਪੜਾਅ ਬਦਲੇ ਵਿੱਚ ਚਲਾਏ ਜਾਂਦੇ ਹਨ - ਅਰਥਾਤ ਸਮਾਨਾਂਤਰ ਇਸ ਪੜਾਅ ਦੇ ਸਾਰੇ ਕੰਮ ਪੂਰੇ ਹੋ ਗਏ ਹਨ,
• ਜੇ ਸਟੇਜ ਫੇਲ ਹੋ ਜਾਂਦੀ ਹੈ (ਅਰਥਾਤ, ਸਟੇਜ ਦਾ ਘੱਟੋ ਘੱਟ ਇੱਕ ਕੰਮ ਅਸਫਲ ਹੋ ਜਾਂਦਾ ਹੈ), ਪਾਈਪਲਾਈਨ ਰੁਕ ਜਾਂਦੀ ਹੈ (ਲਗਭਗ ਹਮੇਸ਼ਾ),
• ਜੇਕਰ ਸਾਰੇ ਪੜਾਅ ਸਫਲਤਾਪੂਰਵਕ ਪੂਰੇ ਹੋ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਪਾਈਪਲਾਈਨ ਨੂੰ ਸਫਲ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ।

ਇਸ ਤਰ੍ਹਾਂ, ਸਾਡੇ ਕੋਲ ਹੈ:

• ਪਾਈਪਲਾਈਨ - ਪੜਾਵਾਂ ਵਿੱਚ ਸੰਗਠਿਤ ਕਾਰਜਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਜਿਸ ਵਿੱਚ ਤੁਸੀਂ ਬਿਲਡ ਕਰ ਸਕਦੇ ਹੋ, ਟੈਸਟ ਕਰ ਸਕਦੇ ਹੋ, ਪੈਕੇਜ ਕੋਡ ਕਰ ਸਕਦੇ ਹੋ, ਇੱਕ ਕਲਾਉਡ ਸੇਵਾ ਵਿੱਚ ਇੱਕ ਮੁਕੰਮਲ ਬਿਲਡ ਨੂੰ ਤੈਨਾਤ ਕਰ ਸਕਦੇ ਹੋ, ਆਦਿ,
• ਪੜਾਅ (ਪੜਾਅ) — ਪਾਈਪਲਾਈਨ ਸੰਗਠਨ ਯੂਨਿਟ, 1+ ਟਾਸਕ ਰੱਖਦਾ ਹੈ,
• ਕੰਮ (ਅੱਯੂਬ) ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਕੰਮ ਦੀ ਇੱਕ ਇਕਾਈ ਹੈ। ਇਸ ਵਿੱਚ ਇੱਕ ਸਕ੍ਰਿਪਟ (ਲਾਜ਼ਮੀ), ਲਾਂਚ ਸ਼ਰਤਾਂ, ਪ੍ਰਕਾਸ਼ਨ/ਕੈਸ਼ਿੰਗ ਕਲਾਤਮਕ ਚੀਜ਼ਾਂ ਲਈ ਸੈਟਿੰਗਾਂ ਅਤੇ ਹੋਰ ਬਹੁਤ ਕੁਝ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ।

ਇਸ ਅਨੁਸਾਰ, ਸੀਆਈ / ਸੀਡੀ ਸਥਾਪਤ ਕਰਨ ਵੇਲੇ ਕਾਰਜਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਬਣਾਉਣ ਲਈ ਹੇਠਾਂ ਆਉਂਦਾ ਹੈ ਜੋ ਕੋਡ ਅਤੇ ਕਲਾਤਮਕ ਚੀਜ਼ਾਂ ਨੂੰ ਬਣਾਉਣ, ਟੈਸਟ ਕਰਨ ਅਤੇ ਪ੍ਰਕਾਸ਼ਤ ਕਰਨ ਲਈ ਸਾਰੀਆਂ ਲੋੜੀਂਦੀਆਂ ਕਾਰਵਾਈਆਂ ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ।

ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ: ਕਿਉਂ?

• Gitlab ਕਿਉਂ?

ਕਿਉਂਕਿ ਜਦੋਂ ਪਾਲਤੂ ਜਾਨਵਰਾਂ ਦੇ ਪ੍ਰੋਜੈਕਟਾਂ ਲਈ ਪ੍ਰਾਈਵੇਟ ਰਿਪੋਜ਼ਟਰੀਆਂ ਬਣਾਉਣਾ ਜ਼ਰੂਰੀ ਹੋ ਗਿਆ ਸੀ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ GitHub 'ਤੇ ਭੁਗਤਾਨ ਕੀਤਾ ਗਿਆ ਸੀ, ਅਤੇ ਮੈਂ ਲਾਲਚੀ ਸੀ. ਰਿਪੋਜ਼ਟਰੀਆਂ ਮੁਫਤ ਹੋ ਗਈਆਂ ਹਨ, ਪਰ ਹੁਣ ਤੱਕ ਇਹ ਮੇਰੇ ਲਈ ਗਿਟਹਬ ਵਿੱਚ ਜਾਣ ਦਾ ਕਾਫ਼ੀ ਕਾਰਨ ਨਹੀਂ ਹੈ।

• Azure DevOps ਪਾਈਪਲਾਈਨਾਂ ਕਿਉਂ ਨਹੀਂ?

ਕਿਉਂਕਿ ਉੱਥੇ ਸੈਟਿੰਗ ਐਲੀਮੈਂਟਰੀ ਹੈ - ਕਮਾਂਡ ਲਾਈਨ ਦੇ ਗਿਆਨ ਦੀ ਵੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਬਾਹਰੀ ਗਿੱਟ ਪ੍ਰਦਾਤਾਵਾਂ ਨਾਲ ਏਕੀਕਰਣ - ਕੁਝ ਕਲਿੱਕਾਂ ਵਿੱਚ, ਰਿਪੋਜ਼ਟਰੀ ਨੂੰ ਕਮਿਟ ਭੇਜਣ ਲਈ SSH ਕੁੰਜੀਆਂ ਦਾ ਆਯਾਤ - ਵੀ, ਪਾਈਪਲਾਈਨ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਕੌਂਫਿਗਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਭਾਵੇਂ ਕਿ ਟੈਂਪਲੇਟ ਤੋਂ ਨਹੀਂ।

ਸ਼ੁਰੂਆਤੀ ਸਥਿਤੀ: ਤੁਹਾਡੇ ਕੋਲ ਕੀ ਹੈ ਅਤੇ ਤੁਸੀਂ ਕੀ ਚਾਹੁੰਦੇ ਹੋ

ਸਾਡੇ ਕੋਲ:

• GitLab ਵਿੱਚ ਰਿਪੋਜ਼ਟਰੀ.

ਅਸੀਂ ਚਾਹੁੰਦੇ ਹਾਂ:

• ਹਰੇਕ ਅਭੇਦ ਦੀ ਬੇਨਤੀ ਲਈ ਆਟੋਮੈਟਿਕ ਅਸੈਂਬਲੀ ਅਤੇ ਟੈਸਟਿੰਗ,
• ਹਰੇਕ ਵਿਲੀਨ ਬੇਨਤੀ ਲਈ ਪੈਕੇਜ ਬਣਾਉਣਾ ਅਤੇ ਮਾਸਟਰ ਨੂੰ ਧੱਕਣਾ, ਬਸ਼ਰਤੇ ਕਿ ਕਮਿਟ ਸੁਨੇਹੇ ਵਿੱਚ ਇੱਕ ਖਾਸ ਲਾਈਨ ਹੋਵੇ,
• Azure DevOps ਵਿੱਚ ਇੱਕ ਪ੍ਰਾਈਵੇਟ ਫੀਡ ਨੂੰ ਬਿਲਟ ਪੈਕੇਜ ਭੇਜਣਾ,
• GitLab ਪੰਨਿਆਂ ਵਿੱਚ ਦਸਤਾਵੇਜ਼ਾਂ ਅਤੇ ਪ੍ਰਕਾਸ਼ਨ ਦੀ ਅਸੈਂਬਲੀ,
• ਬੈਜ!11

ਵਰਣਿਤ ਲੋੜਾਂ ਆਰਗੈਨਿਕ ਤੌਰ 'ਤੇ ਹੇਠਾਂ ਦਿੱਤੇ ਪਾਈਪਲਾਈਨ ਮਾਡਲ 'ਤੇ ਆਉਂਦੀਆਂ ਹਨ:

• ਪੜਾਅ 1 - ਅਸੈਂਬਲੀ
  • ਅਸੀਂ ਕੋਡ ਨੂੰ ਇਕੱਠਾ ਕਰਦੇ ਹਾਂ, ਆਉਟਪੁੱਟ ਫਾਈਲਾਂ ਨੂੰ ਕਲਾਤਮਕ ਚੀਜ਼ਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੇ ਹਾਂ
• ਪੜਾਅ 2 - ਟੈਸਟਿੰਗ
  • ਅਸੀਂ ਬਿਲਡ ਸਟੇਜ ਤੋਂ ਕਲਾਤਮਕ ਚੀਜ਼ਾਂ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ, ਟੈਸਟ ਚਲਾਉਂਦੇ ਹਾਂ, ਕੋਡ ਕਵਰੇਜ ਡੇਟਾ ਇਕੱਠਾ ਕਰਦੇ ਹਾਂ
• ਪੜਾਅ 3 - ਜਮ੍ਹਾਂ ਕਰੋ
  • ਟਾਸਕ 1 - ਨੁਗੇਟ ਪੈਕੇਜ ਬਣਾਓ ਅਤੇ ਇਸਨੂੰ Azure DevOps ਨੂੰ ਭੇਜੋ
  • ਟਾਸਕ 2 - ਅਸੀਂ ਸਾਈਟ ਨੂੰ ਸਰੋਤ ਕੋਡ ਵਿੱਚ xmldoc ਤੋਂ ਇਕੱਤਰ ਕਰਦੇ ਹਾਂ ਅਤੇ ਇਸਨੂੰ GitLab ਪੰਨਿਆਂ ਵਿੱਚ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੇ ਹਾਂ

ਆਓ ਸ਼ੁਰੂ ਕਰੀਏ!

ਸੰਰਚਨਾ ਨੂੰ ਇਕੱਠਾ ਕਰਨਾ

ਖਾਤੇ ਤਿਆਰ ਕਰ ਰਿਹਾ ਹੈ

1. ਵਿੱਚ ਇੱਕ ਖਾਤਾ ਬਣਾਓ ਮਾਈਕਰੋਸਾਫਟ ਅਜ਼ੁਰ

2. ਵੱਲ ਜਾ Azure DevOps

3. ਅਸੀਂ ਇੱਕ ਨਵਾਂ ਪ੍ਰੋਜੈਕਟ ਬਣਾਉਂਦੇ ਹਾਂ

   1. ਨਾਮ - ਕੋਈ ਵੀ
   2. ਦਿੱਖ - ਕੋਈ ਵੀ
      

4. ਜਦੋਂ ਤੁਸੀਂ ਬਣਾਓ ਬਟਨ 'ਤੇ ਕਲਿੱਕ ਕਰਦੇ ਹੋ, ਤਾਂ ਪ੍ਰੋਜੈਕਟ ਬਣਾਇਆ ਜਾਵੇਗਾ ਅਤੇ ਤੁਹਾਨੂੰ ਇਸਦੇ ਪੰਨੇ 'ਤੇ ਰੀਡਾਇਰੈਕਟ ਕੀਤਾ ਜਾਵੇਗਾ। ਇਸ ਪੰਨੇ 'ਤੇ, ਤੁਸੀਂ ਪ੍ਰੋਜੈਕਟ ਸੈਟਿੰਗਾਂ 'ਤੇ ਜਾ ਕੇ ਬੇਲੋੜੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਅਯੋਗ ਕਰ ਸਕਦੇ ਹੋ (ਖੱਬੇ ਪਾਸੇ ਸੂਚੀ ਵਿੱਚ ਹੇਠਲਾ ਲਿੰਕ -> ਸੰਖੇਪ ਜਾਣਕਾਰੀ -> Azure DevOps ਸੇਵਾਵਾਂ ਬਲਾਕ)
   

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. ਦਸਤਾਵੇਜ਼ ਵੇਰਵੇ ਦਿੰਦਾ ਹੈ ਕਿ ਕਿਹੜੀਆਂ ਕੁੰਜੀਆਂ ਸੰਰਚਨਾ ਦੇ ਉੱਪਰਲੇ ਪੱਧਰ 'ਤੇ, ਅਤੇ ਹਰੇਕ ਨੇਸਟਡ ਪੱਧਰ 'ਤੇ ਰੱਖੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ।

ਪਹਿਲਾਂ, ਆਓ ਸੰਰਚਨਾ ਫਾਈਲ ਵਿੱਚ ਡੌਕਰ ਚਿੱਤਰ ਲਈ ਇੱਕ ਲਿੰਕ ਜੋੜੀਏ, ਜਿਸ ਵਿੱਚ ਕੰਮ ਕੀਤੇ ਜਾਣਗੇ। ਇਸਦੇ ਲਈ ਅਸੀਂ ਲੱਭਦੇ ਹਾਂ ਡੌਕਰ ਹੱਬ 'ਤੇ .ਨੈੱਟ ਕੋਰ ਚਿੱਤਰ ਪੰਨਾ. The GitHub ਵੱਖ-ਵੱਖ ਕਾਰਜਾਂ ਲਈ ਕਿਸ ਚਿੱਤਰ ਨੂੰ ਚੁਣਨਾ ਹੈ ਇਸ ਬਾਰੇ ਇੱਕ ਵਿਸਤ੍ਰਿਤ ਗਾਈਡ ਹੈ। .Net Core 3.1 ਦੇ ਨਾਲ ਇੱਕ ਚਿੱਤਰ ਸਾਡੇ ਲਈ ਬਣਾਉਣ ਲਈ ਢੁਕਵਾਂ ਹੈ, ਇਸ ਲਈ ਸੰਰਚਨਾ ਵਿੱਚ ਪਹਿਲੀ ਲਾਈਨ ਸ਼ਾਮਲ ਕਰਨ ਲਈ ਬੇਝਿਜਕ ਮਹਿਸੂਸ ਕਰੋ

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

ਹੁਣ, ਜਦੋਂ ਮਾਈਕਰੋਸਾਫਟ ਇਮੇਜ ਰਿਪੋਜ਼ਟਰੀ ਤੋਂ ਪਾਈਪਲਾਈਨ ਲਾਂਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਨਿਸ਼ਚਿਤ ਚਿੱਤਰ ਡਾਊਨਲੋਡ ਕੀਤਾ ਜਾਵੇਗਾ, ਜਿਸ ਵਿੱਚ ਸੰਰਚਨਾ ਦੇ ਸਾਰੇ ਕਾਰਜ ਕੀਤੇ ਜਾਣਗੇ।

ਅਗਲਾ ਕਦਮ ਜੋੜਨਾ ਹੈ ਪੜਾਅਦੇ ਮੂਲ ਰੂਪ ਵਿੱਚ, 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. wtf?

ਸਭ ਕੁਝ ਤਰਕਪੂਰਨ ਹੈ - ਮੂਲ ਰੂਪ ਵਿੱਚ, ਦੌੜਾਕ (ਟਾਸਕ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਚਲਾਉਣ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਅਤੇ 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 - ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ ਗਿਟਲੈਬ ਪੰਨਿਆਂ ਲਈ ਇੱਕ ਸਰੋਤ ਵਜੋਂ ਰਿਪੋਜ਼ਟਰੀ ਦੇ ਰੂਟ ਵਿੱਚ ਜਨਤਕ ਫੋਲਡਰ ਦੀਆਂ ਸਮੱਗਰੀਆਂ ਨੂੰ ਲੈਂਦਾ ਹੈ। ਕਿਉਂਕਿ ਪ੍ਰੋਜੈਕਟ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਨੇਸਟ ਕੀਤੇ ਇੱਕ ਫੋਲਡਰ ਵਿੱਚ ਸਥਿਤ ਹੋਵੇਗਾ - ਮਾਰਗ ਵਿੱਚ ਲੈਵਲ ਅੱਪ ਕਰਨ ਲਈ ਇੱਕ ਆਉਟਪੁੱਟ ਸ਼ਾਮਲ ਕਰੋ।
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 - ਉੱਥੇ ਸਭ ਕੁਝ ਬਿਲਕੁਲ ਸਿੱਧਾ ਹੈ, ਤੁਸੀਂ ਆਪਣਾ ਬੈਜ ਬਣਾ ਸਕਦੇ ਹੋ ਅਤੇ ਬੇਨਤੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਸਨੂੰ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ।

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

Azure DevOps Artifacts ਤੁਹਾਨੂੰ ਨਵੀਨਤਮ ਸੰਸਕਰਣ ਵਾਲੇ ਪੈਕੇਜਾਂ ਲਈ ਬੈਜ ਬਣਾਉਣ ਦੀ ਆਗਿਆ ਵੀ ਦਿੰਦਾ ਹੈ। ਅਜਿਹਾ ਕਰਨ ਲਈ, 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 ਇਸ ਗਾਈਡ ਨੂੰ ਪੜ੍ਹਨ ਤੋਂ ਬਾਅਦ ਜਾਪਦਾ ਹੈ ਨਾਲੋਂ ਕਿਤੇ ਜ਼ਿਆਦਾ ਵਿਆਪਕ ਅਤੇ ਬਹੁਪੱਖੀ ਹੈ - ਇਹ ਬਿਲਕੁਲ ਵੀ ਸੱਚ ਨਹੀਂ ਹੈ. ਉੱਥੇ ਵੀ ਆਟੋ DevOps ਹੈਦੀ ਇਜਾਜ਼ਤ

ਤੁਹਾਡੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਸਵੈਚਲਿਤ ਤੌਰ 'ਤੇ ਖੋਜੋ, ਬਣਾਓ, ਟੈਸਟ ਕਰੋ, ਤੈਨਾਤ ਕਰੋ ਅਤੇ ਨਿਗਰਾਨੀ ਕਰੋ

ਹੁਣ ਪਲੁਮੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਅਜ਼ੁਰ ਲਈ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਤੈਨਾਤ ਕਰਨ ਲਈ ਇੱਕ ਪਾਈਪਲਾਈਨ ਦੀ ਸੰਰਚਨਾ ਕਰਨ ਅਤੇ ਨਿਸ਼ਾਨਾ ਵਾਤਾਵਰਣ ਨੂੰ ਸਵੈਚਲਿਤ ਤੌਰ 'ਤੇ ਨਿਰਧਾਰਤ ਕਰਨ ਦੀਆਂ ਯੋਜਨਾਵਾਂ ਹਨ, ਜਿਸ ਨੂੰ ਅਗਲੇ ਲੇਖ ਵਿੱਚ ਕਵਰ ਕੀਤਾ ਜਾਵੇਗਾ।

ਸਰੋਤ: www.habr.com