werf 1.1 ਰੀਲੀਜ਼: ਅੱਜ ਬਿਲਡਰ ਲਈ ਸੁਧਾਰ ਅਤੇ ਭਵਿੱਖ ਲਈ ਯੋਜਨਾਵਾਂ

werf ਕੁਬਰਨੇਟਸ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਬਣਾਉਣ ਅਤੇ ਡਿਲੀਵਰ ਕਰਨ ਲਈ ਸਾਡੀ ਓਪਨ ਸੋਰਸ GitOps CLI ਉਪਯੋਗਤਾ ਹੈ। ਵਾਅਦੇ ਮੁਤਾਬਕ, ਵਰਜਨ v1.0 ਦੀ ਰਿਲੀਜ਼ werf ਵਿੱਚ ਨਵੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਜੋੜਨ ਅਤੇ ਰਵਾਇਤੀ ਪਹੁੰਚਾਂ ਨੂੰ ਸੋਧਣ ਦੀ ਸ਼ੁਰੂਆਤ ਨੂੰ ਚਿੰਨ੍ਹਿਤ ਕੀਤਾ। ਹੁਣ ਅਸੀਂ ਰੀਲੀਜ਼ v1.1 ਪੇਸ਼ ਕਰਨ ਵਿੱਚ ਖੁਸ਼ ਹਾਂ, ਜੋ ਕਿ ਵਿਕਾਸ ਵਿੱਚ ਇੱਕ ਵੱਡਾ ਕਦਮ ਹੈ ਅਤੇ ਭਵਿੱਖ ਲਈ ਇੱਕ ਬੁਨਿਆਦ ਹੈ ਕੁਲੈਕਟਰ werf. ਸੰਸਕਰਣ ਵਰਤਮਾਨ ਵਿੱਚ ਉਪਲਬਧ ਹੈ ਚੈਨਲ 1.1 ਈ.ਏ.

ਰੀਲੀਜ਼ ਦਾ ਆਧਾਰ ਸਟੇਜ ਸਟੋਰੇਜ ਦਾ ਨਵਾਂ ਆਰਕੀਟੈਕਚਰ ਹੈ ਅਤੇ ਦੋਵੇਂ ਕੁਲੈਕਟਰਾਂ (ਸਟੈਪਲ ਅਤੇ ਡੌਕਰਫਾਈਲ ਲਈ) ਦੇ ਕੰਮ ਦਾ ਅਨੁਕੂਲਤਾ ਹੈ. ਨਵਾਂ ਸਟੋਰੇਜ ਆਰਕੀਟੈਕਚਰ ਮਲਟੀਪਲ ਮੇਜ਼ਬਾਨਾਂ ਤੋਂ ਵੰਡੀਆਂ ਅਸੈਂਬਲੀਆਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਸੰਭਾਵਨਾ ਨੂੰ ਖੋਲ੍ਹਦਾ ਹੈ ਅਤੇ ਇੱਕੋ ਹੋਸਟ 'ਤੇ ਸਮਾਨਾਂਤਰ ਅਸੈਂਬਲੀਆਂ।

ਕੰਮ ਦੇ ਅਨੁਕੂਲਨ ਵਿੱਚ ਪੜਾਅ ਦੇ ਹਸਤਾਖਰਾਂ ਦੀ ਗਣਨਾ ਕਰਨ ਦੇ ਪੜਾਅ 'ਤੇ ਬੇਲੋੜੀਆਂ ਗਣਨਾਵਾਂ ਤੋਂ ਛੁਟਕਾਰਾ ਪਾਉਣਾ ਅਤੇ ਫਾਈਲ ਚੈੱਕਸਮਾਂ ਦੀ ਗਣਨਾ ਕਰਨ ਲਈ ਵਿਧੀ ਨੂੰ ਵਧੇਰੇ ਕੁਸ਼ਲ ਲੋਕਾਂ ਵਿੱਚ ਬਦਲਣਾ ਸ਼ਾਮਲ ਹੈ। ਇਹ ਓਪਟੀਮਾਈਜੇਸ਼ਨ werf ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪ੍ਰੋਜੈਕਟ ਬਣਾਉਣ ਦੇ ਔਸਤ ਸਮੇਂ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ। ਅਤੇ ਨਿਸ਼ਕਿਰਿਆ ਬਣਾਉਂਦੇ ਹਨ, ਜਦੋਂ ਕੈਸ਼ ਵਿੱਚ ਸਾਰੇ ਪੜਾਅ ਮੌਜੂਦ ਹੁੰਦੇ ਹਨ ਪੜਾਅ - ਸਟੋਰੇਜ਼, ਹੁਣ ਅਸਲ ਵਿੱਚ ਤੇਜ਼ ਹਨ. ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਬਿਲਡ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਨ ਵਿੱਚ 1 ਸਕਿੰਟ ਤੋਂ ਘੱਟ ਸਮਾਂ ਲੱਗੇਗਾ! ਇਹ ਟੀਮਾਂ ਦੇ ਕੰਮ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਪੜਾਵਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਦੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ 'ਤੇ ਵੀ ਲਾਗੂ ਹੁੰਦਾ ਹੈ। werf deploy и werf run.

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

ਆਉ ਅਸੀਂ werf v1.1 ਦੀਆਂ ਮੁੱਖ ਕਾਢਾਂ 'ਤੇ ਡੂੰਘਾਈ ਨਾਲ ਵਿਚਾਰ ਕਰੀਏ, ਅਤੇ ਉਸੇ ਸਮੇਂ ਤੁਹਾਨੂੰ ਭਵਿੱਖ ਦੀਆਂ ਯੋਜਨਾਵਾਂ ਬਾਰੇ ਦੱਸੀਏ।

werf v1.1 ਵਿੱਚ ਕੀ ਬਦਲਿਆ ਹੈ?

ਕੈਸ਼ ਤੋਂ ਪੜਾਵਾਂ ਦੀ ਚੋਣ ਕਰਨ ਲਈ ਨਵਾਂ ਪੜਾਅ ਨਾਮਕਰਨ ਫਾਰਮੈਟ ਅਤੇ ਐਲਗੋਰਿਦਮ

ਨਵਾਂ ਪੜਾਅ ਨਾਮ ਪੀੜ੍ਹੀ ਨਿਯਮ। ਹੁਣ ਹਰੇਕ ਪੜਾਅ ਬਿਲਡ ਇੱਕ ਵਿਲੱਖਣ ਪੜਾਅ ਦਾ ਨਾਮ ਬਣਾਉਂਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ 2 ਭਾਗ ਹੁੰਦੇ ਹਨ: ਇੱਕ ਦਸਤਖਤ (ਜਿਵੇਂ ਕਿ ਇਹ v1.0 ਵਿੱਚ ਸੀ) ਅਤੇ ਇੱਕ ਵਿਲੱਖਣ ਅਸਥਾਈ ਪਛਾਣਕਰਤਾ।

ਉਦਾਹਰਨ ਲਈ, ਪੂਰਾ ਪੜਾਅ ਚਿੱਤਰ ਨਾਮ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦੇ ਸਕਦਾ ਹੈ:

werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835

...ਜਾਂ ਆਮ ਤੌਰ 'ਤੇ:

werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC

ਇੱਥੇ:

• SIGNATURE ਇੱਕ ਸਟੇਜ ਹਸਤਾਖਰ ਹੈ, ਜੋ ਸਟੇਜ ਸਮੱਗਰੀ ਦੇ ਪਛਾਣਕਰਤਾ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਅਤੇ ਗਿੱਟ ਵਿੱਚ ਸੰਪਾਦਨਾਂ ਦੇ ਇਤਿਹਾਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਜਿਸ ਨਾਲ ਇਸ ਸਮੱਗਰੀ ਦੀ ਅਗਵਾਈ ਕੀਤੀ ਗਈ ਹੈ;
• TIMESTAMP_MILLISEC ਇੱਕ ਗਾਰੰਟੀਸ਼ੁਦਾ ਵਿਲੱਖਣ ਚਿੱਤਰ ਪਛਾਣਕਰਤਾ ਹੈ ਜੋ ਇੱਕ ਨਵਾਂ ਚਿੱਤਰ ਬਣਾਉਣ ਸਮੇਂ ਸਿਰਜਿਆ ਜਾਂਦਾ ਹੈ।

ਕੈਸ਼ ਤੋਂ ਪੜਾਵਾਂ ਦੀ ਚੋਣ ਕਰਨ ਲਈ ਐਲਗੋਰਿਦਮ ਗਿੱਟ ਕਮਿਟ ਦੇ ਸਬੰਧਾਂ ਦੀ ਜਾਂਚ ਕਰਨ 'ਤੇ ਅਧਾਰਤ ਹੈ:

1. Werf ਇੱਕ ਖਾਸ ਪੜਾਅ ਦੇ ਦਸਤਖਤ ਦੀ ਗਣਨਾ ਕਰਦਾ ਹੈ.
2. В ਪੜਾਅ - ਸਟੋਰੇਜ਼ ਦਿੱਤੇ ਦਸਤਖਤ ਲਈ ਕਈ ਪੜਾਅ ਹੋ ਸਕਦੇ ਹਨ। Werf ਦਸਤਖਤ ਨਾਲ ਮੇਲ ਖਾਂਦੀਆਂ ਸਾਰੀਆਂ ਪੜਾਵਾਂ ਦੀ ਚੋਣ ਕਰਦਾ ਹੈ।
3. ਜੇ ਮੌਜੂਦਾ ਪੜਾਅ ਗਿੱਟ ਨਾਲ ਜੁੜਿਆ ਹੋਇਆ ਹੈ (ਗਿਟ-ਆਰਕਾਈਵ, ਗਿੱਟ ਪੈਚਾਂ ਨਾਲ ਕਸਟਮ ਪੜਾਅ: install, beforeSetup, setup; ਜਾਂ git-latest-patch), ਫਿਰ werf ਸਿਰਫ਼ ਉਹਨਾਂ ਪੜਾਵਾਂ ਨੂੰ ਚੁਣਦਾ ਹੈ ਜੋ ਇੱਕ ਵਚਨਬੱਧਤਾ ਨਾਲ ਜੁੜੇ ਹੁੰਦੇ ਹਨ ਜੋ ਮੌਜੂਦਾ ਕਮਿਟ (ਜਿਸ ਲਈ ਬਿਲਡ ਕਿਹਾ ਜਾਂਦਾ ਹੈ) ਦਾ ਪੂਰਵਜ ਹੈ।
4. ਬਾਕੀ ਦੇ ਢੁਕਵੇਂ ਪੜਾਵਾਂ ਵਿੱਚੋਂ, ਇੱਕ ਚੁਣਿਆ ਗਿਆ ਹੈ - ਰਚਨਾ ਦੀ ਮਿਤੀ ਦੁਆਰਾ ਸਭ ਤੋਂ ਪੁਰਾਣਾ।

ਵੱਖ-ਵੱਖ ਗਿੱਟ ਸ਼ਾਖਾਵਾਂ ਲਈ ਇੱਕ ਪੜਾਅ ਵਿੱਚ ਇੱਕੋ ਦਸਤਖਤ ਹੋ ਸਕਦੇ ਹਨ। ਪਰ werf ਵੱਖ-ਵੱਖ ਸ਼ਾਖਾਵਾਂ ਨਾਲ ਜੁੜੇ ਕੈਸ਼ ਨੂੰ ਇਹਨਾਂ ਸ਼ਾਖਾਵਾਂ ਦੇ ਵਿਚਕਾਰ ਵਰਤੇ ਜਾਣ ਤੋਂ ਰੋਕੇਗਾ, ਭਾਵੇਂ ਦਸਤਖਤ ਮੇਲ ਖਾਂਦੇ ਹੋਣ।

→ ਦਸਤਾਵੇਜ਼.

ਸਟੇਜ ਸਟੋਰੇਜ ਵਿੱਚ ਪੜਾਵਾਂ ਨੂੰ ਬਣਾਉਣ ਅਤੇ ਬਚਾਉਣ ਲਈ ਨਵਾਂ ਐਲਗੋਰਿਦਮ

ਜੇਕਰ, ਕੈਸ਼ ਤੋਂ ਪੜਾਵਾਂ ਦੀ ਚੋਣ ਕਰਦੇ ਸਮੇਂ, werf ਨੂੰ ਇੱਕ ਢੁਕਵੀਂ ਅਵਸਥਾ ਨਹੀਂ ਮਿਲਦੀ, ਤਾਂ ਇੱਕ ਨਵੇਂ ਪੜਾਅ ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

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

ਇੱਕ ਤਾਜ਼ਾ ਇਕੱਠੇ ਕੀਤੇ ਚਿੱਤਰ ਨੂੰ ਇੱਕ ਵਿਲੱਖਣ ਪਛਾਣਕਰਤਾ ਹੋਣ ਦੀ ਗਾਰੰਟੀ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ TIMESTAMP_MILLISEC (ਨਵਾਂ ਪੜਾਅ ਨਾਮਕਰਨ ਫਾਰਮੈਟ ਦੇਖੋ). ਮਾਮਲੇ ਵਿੱਚ ਪੜਾਅ - ਸਟੋਰੇਜ਼ ਇੱਕ ਢੁਕਵੀਂ ਤਸਵੀਰ ਲੱਭੀ ਜਾਵੇਗੀ, werf ਤਾਜ਼ੇ ਕੰਪਾਇਲ ਕੀਤੇ ਚਿੱਤਰ ਨੂੰ ਰੱਦ ਕਰ ਦੇਵੇਗਾ ਅਤੇ ਕੈਸ਼ ਤੋਂ ਚਿੱਤਰ ਦੀ ਵਰਤੋਂ ਕਰੇਗਾ।

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

→ ਦਸਤਾਵੇਜ਼.

ਡੌਕਰਫਾਈਲ ਬਿਲਡਰ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਸੁਧਾਰ ਕੀਤਾ ਗਿਆ ਹੈ

ਇਸ ਸਮੇਂ, ਡੌਕਰਫਾਈਲ ਤੋਂ ਬਣੇ ਚਿੱਤਰ ਲਈ ਪੜਾਵਾਂ ਦੀ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਇੱਕ ਪੜਾਅ ਹੁੰਦਾ ਹੈ - dockerfile. ਦਸਤਖਤ ਦੀ ਗਣਨਾ ਕਰਦੇ ਸਮੇਂ, ਫਾਈਲਾਂ ਦੇ ਚੈਕਸਮ ਦੀ ਗਣਨਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ context, ਜਿਸ ਦੀ ਵਰਤੋਂ ਅਸੈਂਬਲੀ ਦੌਰਾਨ ਕੀਤੀ ਜਾਵੇਗੀ। ਇਸ ਸੁਧਾਰ ਤੋਂ ਪਹਿਲਾਂ, werf ਵਾਰ-ਵਾਰ ਸਾਰੀਆਂ ਫਾਈਲਾਂ ਵਿੱਚੋਂ ਲੰਘਦਾ ਸੀ ਅਤੇ ਹਰੇਕ ਫਾਈਲ ਦੇ ਸੰਦਰਭ ਅਤੇ ਮੋਡ ਨੂੰ ਜੋੜ ਕੇ ਇੱਕ ਚੈਕਸਮ ਪ੍ਰਾਪਤ ਕਰਦਾ ਸੀ। v1.1 ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋਏ, werf ਇੱਕ ਗਿੱਟ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਗਣਿਤ ਕੀਤੇ ਚੈੱਕਸਮਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦਾ ਹੈ।

ਐਲਗੋਰਿਦਮ 'ਤੇ ਆਧਾਰਿਤ ਹੈ git ls-ਰੁੱਖ. ਵਿੱਚ ਐਲਗੋਰਿਦਮ ਖਾਤੇ ਦੇ ਰਿਕਾਰਡਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦਾ ਹੈ .dockerignore ਅਤੇ ਸਿਰਫ਼ ਲੋੜ ਪੈਣ 'ਤੇ ਹੀ ਫਾਈਲ ਟ੍ਰੀ ਨੂੰ ਮੁੜ-ਮੁੜ ਕੇ ਲੰਘਦਾ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ, ਅਸੀਂ ਫਾਈਲ ਸਿਸਟਮ ਨੂੰ ਪੜ੍ਹਨ ਅਤੇ ਆਕਾਰ 'ਤੇ ਐਲਗੋਰਿਦਮ ਦੀ ਨਿਰਭਰਤਾ ਤੋਂ ਵੱਖ ਹੋ ਗਏ ਹਾਂ context ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਹੈ।

ਐਲਗੋਰਿਦਮ ਅਨਟਰੈਕ ਕੀਤੀਆਂ ਫਾਈਲਾਂ ਦੀ ਵੀ ਜਾਂਚ ਕਰਦਾ ਹੈ ਅਤੇ, ਜੇ ਲੋੜ ਹੋਵੇ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਚੈਕਸਮ ਵਿੱਚ ਖਾਤੇ ਵਿੱਚ ਲੈਂਦਾ ਹੈ।

ਫਾਈਲਾਂ ਨੂੰ ਆਯਾਤ ਕਰਨ ਵੇਲੇ ਬਿਹਤਰ ਕਾਰਗੁਜ਼ਾਰੀ

werf v1.1 ਦੇ ਸੰਸਕਰਣ ਇੱਕ rsync ਸਰਵਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ ਜਦੋਂ ਕਲਾਤਮਕ ਚੀਜ਼ਾਂ ਅਤੇ ਚਿੱਤਰਾਂ ਤੋਂ ਫਾਈਲਾਂ ਨੂੰ ਆਯਾਤ ਕਰਨਾ. ਪਹਿਲਾਂ, ਹੋਸਟ ਸਿਸਟਮ ਤੋਂ ਡਾਇਰੈਕਟਰੀ ਮਾਊਂਟ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਆਯਾਤ ਦੋ ਪੜਾਵਾਂ ਵਿੱਚ ਕੀਤਾ ਜਾਂਦਾ ਸੀ।

ਮੈਕੋਸ 'ਤੇ ਆਯਾਤ ਪ੍ਰਦਰਸ਼ਨ ਹੁਣ ਡੌਕਰ ਵਾਲੀਅਮ ਦੁਆਰਾ ਸੀਮਿਤ ਨਹੀਂ ਹੈ, ਅਤੇ ਆਯਾਤ ਲੀਨਕਸ ਅਤੇ ਵਿੰਡੋਜ਼ ਦੇ ਸਮਾਨ ਸਮੇਂ ਵਿੱਚ ਪੂਰਾ ਹੁੰਦਾ ਹੈ।

ਸਮੱਗਰੀ-ਅਧਾਰਿਤ ਟੈਗਿੰਗ

Werf v1.1 ਚਿੱਤਰ ਸਮੱਗਰੀ ਦੁਆਰਾ ਅਖੌਤੀ ਟੈਗਿੰਗ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ - ਸਮੱਗਰੀ-ਅਧਾਰਿਤ ਟੈਗਿੰਗ. ਨਤੀਜੇ ਵਜੋਂ ਡੌਕਰ ਚਿੱਤਰਾਂ ਦੇ ਟੈਗ ਉਹਨਾਂ ਚਿੱਤਰਾਂ ਦੀ ਸਮੱਗਰੀ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ।

ਕਮਾਂਡ ਚਲਾਉਣ ਵੇਲੇ werf publish --tags-by-stages-signature ਜ werf ci-env --tagging-strategy=stages-signature ਅਖੌਤੀ ਦੇ ਪ੍ਰਕਾਸ਼ਿਤ ਚਿੱਤਰ ਪੜਾਅ ਦੇ ਦਸਤਖਤ ਚਿੱਤਰ। ਹਰੇਕ ਚਿੱਤਰ ਨੂੰ ਇਸ ਚਿੱਤਰ ਦੇ ਪੜਾਵਾਂ ਦੇ ਆਪਣੇ ਦਸਤਖਤ ਨਾਲ ਟੈਗ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜੋ ਕਿ ਹਰੇਕ ਪੜਾਅ ਦੇ ਨਿਯਮਤ ਦਸਤਖਤ ਦੇ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਉਸੇ ਨਿਯਮਾਂ ਅਨੁਸਾਰ ਗਿਣਿਆ ਜਾਂਦਾ ਹੈ, ਪਰ ਚਿੱਤਰ ਦਾ ਇੱਕ ਆਮ ਪਛਾਣਕਰਤਾ ਹੁੰਦਾ ਹੈ।

ਚਿੱਤਰ ਪੜਾਵਾਂ ਦੇ ਦਸਤਖਤ ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ:

1. ਇਸ ਚਿੱਤਰ ਦੀ ਸਮੱਗਰੀ;
2. Git ਪਰਿਵਰਤਨ ਦੇ ਇਤਿਹਾਸ ਜੋ ਇਸ ਸਮਗਰੀ ਦੀ ਅਗਵਾਈ ਕਰਦੇ ਹਨ।

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

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

ਨਾਲ ਹੀ, ਸਮਗਰੀ-ਅਧਾਰਤ ਟੈਗਿੰਗ ਗਿੱਟ ਸ਼ਾਖਾਵਾਂ 'ਤੇ ਟੈਗਿੰਗ ਨਾਲੋਂ ਵਧੇਰੇ ਭਰੋਸੇਮੰਦ ਟੈਗਿੰਗ ਵਿਧੀ ਹੈ, ਕਿਉਂਕਿ ਨਤੀਜੇ ਵਜੋਂ ਚਿੱਤਰਾਂ ਦੀ ਸਮਗਰੀ ਉਸੇ ਸ਼ਾਖਾ ਦੇ ਮਲਟੀਪਲ ਕਮਿਟਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਲਈ CI ਸਿਸਟਮ ਵਿੱਚ ਪਾਈਪਲਾਈਨਾਂ ਨੂੰ ਚਲਾਉਣ ਦੇ ਕ੍ਰਮ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਕਰਦੀ ਹੈ।

ਮਹੱਤਵਪੂਰਣ: ਹੁਣ ਤੋਂ ਸ਼ੁਰੂ ਪੜਾਅ - ਦਸਤਖਤ ਹੈ ਸਿਰਫ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਟੈਗਿੰਗ ਰਣਨੀਤੀ. ਇਹ ਕਮਾਂਡ ਵਿੱਚ ਮੂਲ ਰੂਪ ਵਿੱਚ ਵਰਤਿਆ ਜਾਵੇਗਾ werf ci-env (ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਕੋਈ ਵੱਖਰੀ ਟੈਗਿੰਗ ਸਕੀਮ ਨਹੀਂ ਦਿੰਦੇ ਹੋ)।

→ ਦਸਤਾਵੇਜ਼. ਇਸ ਵਿਸ਼ੇਸ਼ਤਾ ਲਈ ਇੱਕ ਵੱਖਰਾ ਪ੍ਰਕਾਸ਼ਨ ਵੀ ਸਮਰਪਿਤ ਕੀਤਾ ਜਾਵੇਗਾ। ਅੱਪਡੇਟ ਕੀਤਾ (3 ਅਪ੍ਰੈਲ): ਵੇਰਵਿਆਂ ਵਾਲਾ ਲੇਖ ਪ੍ਰਕਾਸ਼ਿਤ.

ਲੌਗਿੰਗ ਪੱਧਰ

ਉਪਭੋਗਤਾ ਕੋਲ ਹੁਣ ਆਉਟਪੁੱਟ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਨ, ਲੌਗਿੰਗ ਪੱਧਰ ਨੂੰ ਸੈੱਟ ਕਰਨ ਅਤੇ ਡੀਬਗਿੰਗ ਜਾਣਕਾਰੀ ਦੇ ਨਾਲ ਕੰਮ ਕਰਨ ਦਾ ਮੌਕਾ ਹੈ। ਵਿਕਲਪ ਸ਼ਾਮਲ ਕੀਤੇ ਗਏ --log-quiet, --log-verbose, --log-debug.

ਮੂਲ ਰੂਪ ਵਿੱਚ, ਆਉਟਪੁੱਟ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ ਜਾਣਕਾਰੀ ਹੁੰਦੀ ਹੈ:

ਵਰਬੋਜ਼ ਆਉਟਪੁੱਟ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ (--log-verbose) ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ werf ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ:

ਵਿਸਤ੍ਰਿਤ ਆਉਟਪੁੱਟ (--log-debug), werf ਡੀਬੱਗਿੰਗ ਜਾਣਕਾਰੀ ਤੋਂ ਇਲਾਵਾ, ਵਰਤੀਆਂ ਗਈਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੇ ਲੌਗ ਵੀ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਡੌਕਰ ਰਜਿਸਟਰੀ ਨਾਲ ਕਿਵੇਂ ਗੱਲਬਾਤ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਸਥਾਨਾਂ ਨੂੰ ਵੀ ਰਿਕਾਰਡ ਕਰੋ ਜਿੱਥੇ ਕਾਫ਼ੀ ਸਮਾਂ ਬਿਤਾਇਆ ਜਾਂਦਾ ਹੈ:

ਹੋਰ ਯੋਜਨਾਵਾਂ

ਸਾਵਧਾਨ ਹੇਠਾਂ ਦੱਸੇ ਗਏ ਵਿਕਲਪਾਂ ਨੂੰ ਚਿੰਨ੍ਹਿਤ ਕੀਤਾ ਗਿਆ ਹੈ v1.1 ਇਸ ਸੰਸਕਰਣ ਵਿੱਚ ਉਪਲਬਧ ਹੋ ਜਾਣਗੇ, ਇਹਨਾਂ ਵਿੱਚੋਂ ਬਹੁਤ ਸਾਰੇ ਨੇੜਲੇ ਭਵਿੱਖ ਵਿੱਚ। ਅੱਪਡੇਟ ਆਟੋ-ਅੱਪਡੇਟਸ ਰਾਹੀਂ ਆਉਣਗੇ ਮਲਟੀਵਰਫ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ. ਇਹ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ v1.1 ਫੰਕਸ਼ਨਾਂ ਦੇ ਸਥਿਰ ਹਿੱਸੇ ਨੂੰ ਪ੍ਰਭਾਵਤ ਨਹੀਂ ਕਰਦੀਆਂ; ਉਹਨਾਂ ਦੀ ਦਿੱਖ ਨੂੰ ਮੌਜੂਦਾ ਸੰਰਚਨਾਵਾਂ ਵਿੱਚ ਦਸਤੀ ਉਪਭੋਗਤਾ ਦਖਲ ਦੀ ਲੋੜ ਨਹੀਂ ਹੋਵੇਗੀ।

ਵੱਖ-ਵੱਖ ਡੌਕਰ ਰਜਿਸਟਰੀ ਲਾਗੂਕਰਨ (ਨਵਾਂ) ਲਈ ਪੂਰਾ ਸਮਰਥਨ

• ਸੰਸਕਰਣ: v1.1
• ਮਿਤੀਆਂ: ਮਾਰਚ
• ਮੁੱਦੇ

werf ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਉਪਭੋਗਤਾ ਨੂੰ ਬਿਨਾਂ ਕਿਸੇ ਪਾਬੰਦੀਆਂ ਦੇ ਇੱਕ ਕਸਟਮ ਲਾਗੂਕਰਨ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਟੀਚਾ ਹੈ।

ਵਰਤਮਾਨ ਵਿੱਚ, ਅਸੀਂ ਨਿਮਨਲਿਖਤ ਹੱਲਾਂ ਦੀ ਪਛਾਣ ਕੀਤੀ ਹੈ ਜਿਸ ਲਈ ਅਸੀਂ ਪੂਰੀ ਸਹਾਇਤਾ ਦੀ ਗਰੰਟੀ ਦੇਣ ਜਾ ਰਹੇ ਹਾਂ:

• ਡਿਫੌਲਟ (ਲਾਇਬ੍ਰੇਰੀ/ਰਜਿਸਟਰੀ)*,
• AWS ECR
• ਅਜ਼ੂਰ*,
• ਡੌਕਰ ਹੱਬ
• GCR*,
• GitHub ਪੈਕੇਜ
• GitLab ਰਜਿਸਟਰੀ*,
• ਬੰਦਰਗਾਹ*,
• ਕਵੇ.

ਹੱਲ ਜੋ ਵਰਤਮਾਨ ਵਿੱਚ werf ਦੁਆਰਾ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਮਰਥਿਤ ਹਨ ਇੱਕ ਤਾਰੇ ਨਾਲ ਚਿੰਨ੍ਹਿਤ ਕੀਤੇ ਗਏ ਹਨ। ਦੂਜਿਆਂ ਲਈ ਸਹਾਇਤਾ ਹੈ, ਪਰ ਸੀਮਾਵਾਂ ਦੇ ਨਾਲ।

ਦੋ ਮੁੱਖ ਸਮੱਸਿਆਵਾਂ ਦੀ ਪਛਾਣ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ:

• ਕੁਝ ਹੱਲ ਡੌਕਰ ਰਜਿਸਟਰੀ API ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਟੈਗ ਹਟਾਉਣ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦੇ, ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ werf ਦੇ ਆਟੋਮੈਟਿਕ ਕਲੀਨਅੱਪ ਦੀ ਵਰਤੋਂ ਕਰਨ ਤੋਂ ਰੋਕਦੇ ਹਨ। ਇਹ AWS ECR, Docker Hub, ਅਤੇ GitHub ਪੈਕੇਜਾਂ ਲਈ ਸੱਚ ਹੈ।
• ਕੁਝ ਹੱਲ ਅਖੌਤੀ ਨੇਸਟਡ ਰਿਪੋਜ਼ਟਰੀਆਂ (ਡੌਕਰ ਹੱਬ, ਗਿੱਟਹਬ ਪੈਕੇਜ ਅਤੇ ਕਵੇ) ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦੇ ਹਨ ਜਾਂ ਕਰਦੇ ਹਨ, ਪਰ ਉਪਭੋਗਤਾ ਨੂੰ UI ਜਾਂ API (AWS ECR) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਉਹਨਾਂ ਨੂੰ ਹੱਥੀਂ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ।

ਅਸੀਂ ਹੱਲਾਂ ਦੇ ਮੂਲ API ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਹਨਾਂ ਅਤੇ ਹੋਰ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਜਾ ਰਹੇ ਹਾਂ। ਇਸ ਕੰਮ ਵਿੱਚ ਉਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਲਈ ਟੈਸਟਾਂ ਦੇ ਨਾਲ ਵਰਫ ਓਪਰੇਸ਼ਨ ਦੇ ਪੂਰੇ ਚੱਕਰ ਨੂੰ ਕਵਰ ਕਰਨਾ ਵੀ ਸ਼ਾਮਲ ਹੈ।

ਵਿਤਰਿਤ ਚਿੱਤਰ ਬਿਲਡ (↑)

• ਸੰਸਕਰਣ: v1.2 v1.1 (ਇਸ ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਤਰਜੀਹ ਵਧਾ ਦਿੱਤੀ ਗਈ ਹੈ)
• ਮਿਤੀਆਂ: ਮਾਰਚ-ਅਪ੍ਰੈਲ ਮਾਰਚ
• ਮੁੱਦੇ

ਇਸ ਸਮੇਂ, werf v1.0 ਅਤੇ v1.1 ਦੀ ਵਰਤੋਂ ਚਿੱਤਰਾਂ ਨੂੰ ਬਣਾਉਣ ਅਤੇ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ Kubernetes 'ਤੇ ਤੈਨਾਤ ਕਰਨ ਲਈ ਸਿਰਫ਼ ਇੱਕ ਸਮਰਪਿਤ ਹੋਸਟ 'ਤੇ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ।

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

ਪਹਿਲਾਂ, ਜਦੋਂ ਵਰਫ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਅਜੇ ਵੀ ਡੈਪ ਕਿਹਾ ਜਾਂਦਾ ਸੀ, ਇਸ ਕੋਲ ਅਜਿਹਾ ਮੌਕਾ ਸੀ. ਹਾਲਾਂਕਿ, ਸਾਨੂੰ ਕਈ ਮੁੱਦਿਆਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ werf ਵਿੱਚ ਇਸ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਲਾਗੂ ਕਰਦੇ ਸਮੇਂ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ।

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

GitHub ਕਾਰਵਾਈਆਂ (ਨਵਾਂ) ਲਈ ਅਧਿਕਾਰਤ ਸਮਰਥਨ

• ਸੰਸਕਰਣ: v1.1
• ਮਿਤੀਆਂ: ਮਾਰਚ
• ਮੁੱਦੇ

werf ਦਸਤਾਵੇਜ਼ (ਸੈਕਸ਼ਨ ਹਵਾਲਾ и ਦੀ ਅਗਵਾਈ), ਅਤੇ ਨਾਲ ਹੀ werf ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਅਧਿਕਾਰਤ GitHub ਐਕਸ਼ਨ।

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਹ ਵੇਰਫ ਨੂੰ ਅਲੌਕਿਕ ਦੌੜਾਕਾਂ 'ਤੇ ਕੰਮ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦੇਵੇਗਾ।

CI ਸਿਸਟਮ ਦੇ ਨਾਲ ਉਪਭੋਗਤਾ ਦੀ ਆਪਸੀ ਤਾਲਮੇਲ ਦਾ ਮਕੈਨਿਕਸ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਬਣਾਉਣ/ਰੋਲ ਆਊਟ ਕਰਨ ਲਈ ਕੁਝ ਕਾਰਵਾਈਆਂ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਪੁੱਲ ਬੇਨਤੀਆਂ 'ਤੇ ਲੇਬਲ ਲਗਾਉਣ 'ਤੇ ਅਧਾਰਤ ਹੋਵੇਗਾ।

werf (↓) ਨਾਲ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦਾ ਸਥਾਨਕ ਵਿਕਾਸ ਅਤੇ ਤੈਨਾਤੀ

• ਸੰਸਕਰਣ: v1.1
• ਮਿਤੀਆਂ: ਜਨਵਰੀ-ਫਰਵਰੀ ਅਪ੍ਰੈਲ
• ਮੁੱਦੇ

ਮੁੱਖ ਟੀਚਾ ਬਕਸੇ ਤੋਂ ਬਾਹਰ, ਗੁੰਝਲਦਾਰ ਕਾਰਵਾਈਆਂ ਦੇ ਬਿਨਾਂ, ਸਥਾਨਕ ਅਤੇ ਉਤਪਾਦਨ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਤੈਨਾਤ ਕਰਨ ਲਈ ਇੱਕ ਸਿੰਗਲ ਯੂਨੀਫਾਈਡ ਸੰਰਚਨਾ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨਾ ਹੈ।

werf ਨੂੰ ਇੱਕ ਓਪਰੇਟਿੰਗ ਮੋਡ ਦੀ ਵੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰਨਾ ਅਤੇ ਡੀਬੱਗਿੰਗ ਲਈ ਚੱਲ ਰਹੀ ਐਪਲੀਕੇਸ਼ਨ ਤੋਂ ਤੁਰੰਤ ਫੀਡਬੈਕ ਪ੍ਰਾਪਤ ਕਰਨਾ ਸੁਵਿਧਾਜਨਕ ਹੋਵੇਗਾ।

ਨਵਾਂ ਸਫਾਈ ਐਲਗੋਰਿਦਮ (ਨਵਾਂ)

• ਸੰਸਕਰਣ: v1.1
• ਮਿਤੀਆਂ: ਅਪ੍ਰੈਲ
• ਮੁੱਦੇ

ਵਿਧੀ ਵਿੱਚ werf v1.1 ਦੇ ਮੌਜੂਦਾ ਸੰਸਕਰਣ ਵਿੱਚ cleanup ਸਮੱਗਰੀ-ਅਧਾਰਤ ਟੈਗਿੰਗ ਸਕੀਮ ਲਈ ਚਿੱਤਰਾਂ ਨੂੰ ਸਾਫ਼ ਕਰਨ ਦਾ ਕੋਈ ਪ੍ਰਬੰਧ ਨਹੀਂ ਹੈ - ਇਹ ਚਿੱਤਰ ਇਕੱਠੇ ਹੋਣਗੇ।

ਨਾਲ ਹੀ, werf (v1.0 ਅਤੇ v1.1) ਦਾ ਮੌਜੂਦਾ ਸੰਸਕਰਣ ਟੈਗਿੰਗ ਸਕੀਮਾਂ ਦੇ ਅਧੀਨ ਪ੍ਰਕਾਸ਼ਿਤ ਚਿੱਤਰਾਂ ਲਈ ਵੱਖ-ਵੱਖ ਸਫਾਈ ਨੀਤੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ: Git ਬ੍ਰਾਂਚ, Git ਟੈਗ ਜਾਂ Git ਕਮਿਟ।

ਸਾਰੀਆਂ ਟੈਗਿੰਗ ਸਕੀਮਾਂ ਲਈ ਏਕੀਕ੍ਰਿਤ, ਗਿਟ ਵਿੱਚ ਪ੍ਰਤੀਬੱਧਤਾਵਾਂ ਦੇ ਇਤਿਹਾਸ ਦੇ ਅਧਾਰ ਤੇ ਚਿੱਤਰਾਂ ਦੀ ਸਫਾਈ ਲਈ ਇੱਕ ਨਵਾਂ ਐਲਗੋਰਿਦਮ ਖੋਜਿਆ ਗਿਆ ਹੈ:

• ਹਰੇਕ git HEAD (ਸ਼ਾਖਾਵਾਂ ਅਤੇ ਟੈਗਸ) ਲਈ N1 ਸਭ ਤੋਂ ਤਾਜ਼ਾ ਕਮਿਟਾਂ ਨਾਲ ਜੁੜੇ N2 ਚਿੱਤਰਾਂ ਤੋਂ ਵੱਧ ਨਾ ਰੱਖੋ।
• ਹਰੇਕ ਗਿਟ ਹੈਡ (ਸ਼ਾਖਾਵਾਂ ਅਤੇ ਟੈਗਸ) ਲਈ N1 ਸਭ ਤੋਂ ਤਾਜ਼ਾ ਕਮਿਟਾਂ ਨਾਲ ਜੁੜੇ N2 ਸਟੇਜ ਚਿੱਤਰਾਂ ਤੋਂ ਵੱਧ ਸਟੋਰ ਨਾ ਕਰੋ।
• ਉਹਨਾਂ ਸਾਰੀਆਂ ਤਸਵੀਰਾਂ ਨੂੰ ਸਟੋਰ ਕਰੋ ਜੋ ਕਿਸੇ ਵੀ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਸਰੋਤਾਂ ਵਿੱਚ ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ (ਸੰਰਚਨਾ ਫਾਈਲ ਦੇ ਸਾਰੇ ਕਿਊਬ ਸੰਦਰਭ ਅਤੇ ਨੇਮਸਪੇਸ ਸਕੈਨ ਕੀਤੇ ਗਏ ਹਨ; ਤੁਸੀਂ ਵਿਸ਼ੇਸ਼ ਵਿਕਲਪਾਂ ਨਾਲ ਇਸ ਵਿਵਹਾਰ ਨੂੰ ਸੀਮਿਤ ਕਰ ਸਕਦੇ ਹੋ)।
• ਹੈਲਮ ਰੀਲੀਜ਼ਾਂ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਕੀਤੇ ਸਰੋਤ ਸੰਰਚਨਾ ਮੈਨੀਫੈਸਟ ਵਿੱਚ ਵਰਤੀਆਂ ਜਾਣ ਵਾਲੀਆਂ ਸਾਰੀਆਂ ਤਸਵੀਰਾਂ ਨੂੰ ਸਟੋਰ ਕਰੋ।
• ਇੱਕ ਚਿੱਤਰ ਨੂੰ ਮਿਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਜੇਕਰ ਇਹ git ਤੋਂ ਕਿਸੇ ਵੀ HEAD ਨਾਲ ਸੰਬੰਧਿਤ ਨਹੀਂ ਹੈ (ਉਦਾਹਰਣ ਵਜੋਂ, ਕਿਉਂਕਿ ਸੰਬੰਧਿਤ HEAD ਖੁਦ ਮਿਟਾ ਦਿੱਤਾ ਗਿਆ ਸੀ) ਅਤੇ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਅਤੇ ਹੈਲਮ ਰੀਲੀਜ਼ ਵਿੱਚ ਕਿਸੇ ਵੀ ਮੈਨੀਫੈਸਟ ਵਿੱਚ ਨਹੀਂ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।

ਸਮਾਨਾਂਤਰ ਚਿੱਤਰ ਬਿਲਡਿੰਗ (↓)

• ਸੰਸਕਰਣ: v1.1
• ਮਿਤੀਆਂ: ਜਨਵਰੀ-ਫਰਵਰੀ ਅਪ੍ਰੈਲ*

ਵਰਫ ਦਾ ਮੌਜੂਦਾ ਸੰਸਕਰਣ ਚਿੱਤਰਾਂ ਅਤੇ ਕਲਾਤਮਕ ਚੀਜ਼ਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਹੈ werf.yaml, ਕ੍ਰਮਵਾਰ. ਚਿੱਤਰਾਂ ਅਤੇ ਕਲਾਤਮਕ ਚੀਜ਼ਾਂ ਦੇ ਸੁਤੰਤਰ ਪੜਾਵਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸਮਾਨਾਂਤਰ ਬਣਾਉਣ ਦੇ ਨਾਲ ਨਾਲ ਸੁਵਿਧਾਜਨਕ ਅਤੇ ਜਾਣਕਾਰੀ ਭਰਪੂਰ ਆਉਟਪੁੱਟ ਪ੍ਰਦਾਨ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ।

* ਨੋਟ: ਡਿਸਟ੍ਰੀਬਿਊਟਡ ਅਸੈਂਬਲੀ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਵਧੀ ਹੋਈ ਤਰਜੀਹ ਦੇ ਕਾਰਨ ਡੈੱਡਲਾਈਨ ਨੂੰ ਬਦਲ ਦਿੱਤਾ ਗਿਆ ਹੈ, ਜਿਸ ਨਾਲ ਹੋਰ ਹਰੀਜੱਟਲ ਸਕੇਲਿੰਗ ਸਮਰੱਥਾਵਾਂ ਸ਼ਾਮਲ ਹੋਣਗੀਆਂ, ਨਾਲ ਹੀ GitHub ਐਕਸ਼ਨਜ਼ ਦੇ ਨਾਲ werf ਦੀ ਵਰਤੋਂ ਵੀ ਹੋਵੇਗੀ। ਪੈਰਲਲ ਅਸੈਂਬਲੀ ਅਗਲਾ ਓਪਟੀਮਾਈਜੇਸ਼ਨ ਕਦਮ ਹੈ, ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਅਸੈਂਬਲ ਕਰਨ ਵੇਲੇ ਵਰਟੀਕਲ ਸਕੇਲੇਬਿਲਟੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

ਹੈਲਮ 3 (↓) ਵਿੱਚ ਤਬਦੀਲੀ

• ਸੰਸਕਰਣ: v1.2
• ਮਿਤੀਆਂ: ਫਰਵਰੀ-ਮਾਰਚ ਮਈ*

ਨਵੇਂ ਕੋਡਬੇਸ ਵਿੱਚ ਮਾਈਗ੍ਰੇਸ਼ਨ ਸ਼ਾਮਲ ਹੈ ਹੈਲਮ 3 ਅਤੇ ਮੌਜੂਦਾ ਸਥਾਪਨਾਵਾਂ ਨੂੰ ਮਾਈਗਰੇਟ ਕਰਨ ਦਾ ਇੱਕ ਸਾਬਤ, ਸੁਵਿਧਾਜਨਕ ਤਰੀਕਾ।

* ਨੋਟ: ਹੈਲਮ 3 ਨੂੰ ਬਦਲਣ ਨਾਲ werf ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਸ਼ਾਮਲ ਨਹੀਂ ਹੋਣਗੀਆਂ, ਕਿਉਂਕਿ ਹੈਲਮ 3 ਦੀਆਂ ਸਾਰੀਆਂ ਮੁੱਖ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ (3-ਵੇਅ-ਮਰਜ ਅਤੇ ਕੋਈ ਟਿਲਰ ਨਹੀਂ) ਪਹਿਲਾਂ ਹੀ ਵਰਫ ਵਿੱਚ ਲਾਗੂ ਹਨ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਵਰਫ ਕੋਲ ਹੈ ਵਾਧੂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦਰਸਾਏ ਗਏ ਲੋਕਾਂ ਤੋਂ ਇਲਾਵਾ। ਹਾਲਾਂਕਿ, ਇਹ ਪਰਿਵਰਤਨ ਸਾਡੀਆਂ ਯੋਜਨਾਵਾਂ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਲਾਗੂ ਕੀਤਾ ਜਾਵੇਗਾ।

ਕੁਬਰਨੇਟਸ ਕੌਂਫਿਗਰੇਸ਼ਨ (↓) ਦਾ ਵਰਣਨ ਕਰਨ ਲਈ Jsonnet

• ਸੰਸਕਰਣ: v1.2
• ਮਿਤੀਆਂ: ਜਨਵਰੀ-ਫਰਵਰੀ ਅਪ੍ਰੈਲ-ਮਈ

Werf Jsonnet ਫਾਰਮੈਟ ਵਿੱਚ Kubernetes ਲਈ ਸੰਰਚਨਾ ਵਰਣਨ ਦਾ ਸਮਰਥਨ ਕਰੇਗਾ। ਇਸ ਦੇ ਨਾਲ ਹੀ, werf ਹੈਲਮ ਦੇ ਅਨੁਕੂਲ ਰਹੇਗਾ ਅਤੇ ਵਰਣਨ ਫਾਰਮੈਟ ਦੀ ਚੋਣ ਹੋਵੇਗੀ।

ਕਾਰਨ ਇਹ ਹੈ ਕਿ ਗੋ ਟੈਂਪਲੇਟਸ, ਬਹੁਤ ਸਾਰੇ ਲੋਕਾਂ ਦੇ ਅਨੁਸਾਰ, ਇੱਕ ਉੱਚ ਪ੍ਰਵੇਸ਼ ਰੁਕਾਵਟ ਹੈ, ਅਤੇ ਇਹਨਾਂ ਟੈਂਪਲੇਟਾਂ ਦੇ ਕੋਡ ਦੀ ਸਮਝਦਾਰੀ ਨੂੰ ਵੀ ਨੁਕਸਾਨ ਹੁੰਦਾ ਹੈ.

ਹੋਰ Kubernetes ਸੰਰਚਨਾ ਵੇਰਵਾ ਸਿਸਟਮ (ਉਦਾਹਰਨ ਲਈ, Kustomize) ਨੂੰ ਪੇਸ਼ ਕਰਨ ਦੀ ਸੰਭਾਵਨਾ 'ਤੇ ਵੀ ਵਿਚਾਰ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ।

ਕੁਬਰਨੇਟਸ (↓) ਦੇ ਅੰਦਰ ਕੰਮ ਕਰਨਾ

• ਸੰਸਕਰਣ: v1.2
• ਮਿਤੀਆਂ: ਅਪ੍ਰੈਲ-ਮਈ ਮਈ-ਜੂਨ

ਟੀਚਾ: ਇਹ ਸੁਨਿਸ਼ਚਿਤ ਕਰੋ ਕਿ ਚਿੱਤਰ ਬਣਾਏ ਗਏ ਹਨ ਅਤੇ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਦੌੜਾਕਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਐਪਲੀਕੇਸ਼ਨ ਡਿਲੀਵਰ ਕੀਤੀ ਗਈ ਹੈ। ਉਹ. ਨਵੇਂ ਚਿੱਤਰ ਬਣਾਏ ਜਾ ਸਕਦੇ ਹਨ, ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ, ਸਾਫ਼ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ ਅਤੇ ਸਿੱਧੇ ਕੁਬਰਨੇਟਸ ਪੌਡਸ ਤੋਂ ਤਾਇਨਾਤ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ।

ਇਸ ਸਮਰੱਥਾ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਪਹਿਲਾਂ ਵੰਡੀਆਂ ਗਈਆਂ ਤਸਵੀਰਾਂ ਬਣਾਉਣ ਦੇ ਯੋਗ ਹੋਣ ਦੀ ਲੋੜ ਹੈ (ਉਪਰੋਕਤ ਬਿੰਦੂ ਦੇਖੋ).

ਇਸ ਨੂੰ ਡੌਕਰ ਸਰਵਰ ਤੋਂ ਬਿਨਾਂ ਬਿਲਡਰ ਦੇ ਓਪਰੇਟਿੰਗ ਮੋਡ ਲਈ ਸਮਰਥਨ ਦੀ ਵੀ ਲੋੜ ਹੁੰਦੀ ਹੈ (ਜਿਵੇਂ ਕਿ ਕਾਨੀਕੋ-ਵਰਗੇ ਬਿਲਡ ਜਾਂ ਯੂਜ਼ਰਸਪੇਸ ਵਿੱਚ ਬਿਲਡ)।

Werf ਕੁਬਰਨੇਟਸ 'ਤੇ ਨਾ ਸਿਰਫ਼ ਡੌਕਰਫਾਈਲ ਦੇ ਨਾਲ, ਸਗੋਂ ਇਸਦੇ ਸਟੈਪਲ ਬਿਲਡਰ ਦੇ ਨਾਲ ਵਾਧੇ ਵਾਲੇ ਪੁਨਰ-ਨਿਰਮਾਣ ਅਤੇ ਜਵਾਬਦੇਹ ਨਾਲ ਵੀ ਸਮਰਥਨ ਕਰੇਗਾ।

ਖੁੱਲੇ ਵਿਕਾਸ ਵੱਲ ਇੱਕ ਕਦਮ

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

ਕਾਫ਼ੀ ਹਾਲ ਹੀ ਵਿੱਚ ਇਸਨੂੰ ਬਦਲਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਗਿਆ ਸੀ GitHub ਪ੍ਰੋਜੈਕਟ ਬੋਰਡ ਸਾਡੀ ਟੀਮ ਦੀ ਕਾਰਜ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਪ੍ਰਗਟ ਕਰਨ ਲਈ। ਹੁਣ ਤੁਸੀਂ ਹੇਠ ਲਿਖੇ ਖੇਤਰਾਂ ਵਿੱਚ ਤਤਕਾਲ ਯੋਜਨਾਵਾਂ ਦੇ ਨਾਲ-ਨਾਲ ਮੌਜੂਦਾ ਕੰਮ ਵੀ ਦੇਖ ਸਕਦੇ ਹੋ:

• ਦਸਤਾਵੇਜ਼ ਅਤੇ ਸਾਈਟ;
• ਟੈਸਟਿੰਗ;
• ਬੱਗ ਅਤੇ ਖਰਾਬ UX;
• 1.1.

ਮੁੱਦਿਆਂ ਦੇ ਨਾਲ ਬਹੁਤ ਸਾਰਾ ਕੰਮ ਕੀਤਾ ਗਿਆ ਹੈ:

• ਅਪ੍ਰਸੰਗਿਕ ਨੂੰ ਹਟਾ ਦਿੱਤਾ.
• ਮੌਜੂਦਾ ਲੋਕਾਂ ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਫਾਰਮੈਟ ਵਿੱਚ ਲਿਆਂਦਾ ਗਿਆ ਹੈ, ਜਿਸ ਵਿੱਚ ਕਾਫ਼ੀ ਗਿਣਤੀ ਵਿੱਚ ਵੇਰਵੇ ਅਤੇ ਵੇਰਵੇ ਹਨ.
• ਵਿਚਾਰਾਂ ਅਤੇ ਸੁਝਾਵਾਂ ਦੇ ਨਾਲ ਨਵੇਂ ਮੁੱਦੇ ਸ਼ਾਮਲ ਕੀਤੇ ਗਏ ਹਨ।

ਸੰਸਕਰਣ v1.1 ਨੂੰ ਕਿਵੇਂ ਸਮਰੱਥ ਕਰੀਏ

ਸੰਸਕਰਣ ਵਰਤਮਾਨ ਵਿੱਚ ਉਪਲਬਧ ਹੈ ਚੈਨਲ 1.1 ਈ.ਏ (ਚੈਨਲਾਂ ਵਿੱਚ ਸਥਿਰ и ਚੱਟਾਨ-ਠੋਸ ਹਾਲਾਂਕਿ, ਸਥਿਰਤਾ ਹੋਣ ਦੇ ਨਾਲ ਹੀ ਰੀਲੀਜ਼ ਦਿਖਾਈ ਦੇਣਗੇ ea ਆਪਣੇ ਆਪ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਵਰਤੋਂ ਲਈ ਕਾਫ਼ੀ ਸਥਿਰ ਹੈ, ਕਿਉਂਕਿ ਚੈਨਲਾਂ ਰਾਹੀਂ ਲੰਘਿਆ ਐਲਫਾ и ਬੀਟਾ). ਕਿਰਿਆਸ਼ੀਲ ਕੀਤਾ ਮਲਟੀਵਰਫ ਦੁਆਰਾ ਹੇਠ ਲਿਖੇ ਤਰੀਕੇ ਨਾਲ:

source $(multiwerf use 1.1 ea)
werf COMMAND ...

ਸਿੱਟਾ

ਸਟੈਪਲ ਅਤੇ ਡੌਕਰਫਾਈਲ ਬਿਲਡਰਾਂ ਲਈ ਨਵੀਂ ਸਟੇਜ ਸਟੋਰੇਜ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਬਿਲਡਰ ਓਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਵਰਫ ਵਿੱਚ ਵੰਡੇ ਅਤੇ ਸਮਾਨਾਂਤਰ ਬਿਲਡਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਸੰਭਾਵਨਾ ਨੂੰ ਖੋਲ੍ਹਦੇ ਹਨ। ਇਹ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਜਲਦੀ ਹੀ ਉਸੇ v1.1 ਰੀਲੀਜ਼ ਵਿੱਚ ਦਿਖਾਈ ਦੇਣਗੀਆਂ ਅਤੇ ਆਟੋ-ਅੱਪਡੇਟ ਵਿਧੀ (ਉਪਭੋਗਤਿਆਂ ਲਈ) ਦੁਆਰਾ ਆਪਣੇ ਆਪ ਉਪਲਬਧ ਹੋ ਜਾਣਗੀਆਂ ਮਲਟੀਵਰਫ).

ਇਸ ਰੀਲੀਜ਼ ਵਿੱਚ, ਚਿੱਤਰ ਸਮੱਗਰੀ 'ਤੇ ਅਧਾਰਤ ਇੱਕ ਟੈਗਿੰਗ ਰਣਨੀਤੀ ਸ਼ਾਮਲ ਕੀਤੀ ਗਈ ਹੈ - ਸਮੱਗਰੀ-ਅਧਾਰਿਤ ਟੈਗਿੰਗ, ਜੋ ਕਿ ਡਿਫਾਲਟ ਰਣਨੀਤੀ ਬਣ ਗਈ ਹੈ। ਮੁੱਖ ਕਮਾਂਡ ਲੌਗ ਨੂੰ ਵੀ ਦੁਬਾਰਾ ਕੰਮ ਕੀਤਾ ਗਿਆ ਹੈ: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

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

ਖ਼ਬਰਾਂ ਦਾ ਪਾਲਣ ਕਰੋ! ਅਤੇ 'ਤੇ ਸਾਨੂੰ ਮਿਲਣ ਲਈ ਨਾ ਭੁੱਲੋ GitHubਕੋਈ ਮੁੱਦਾ ਬਣਾਉਣ ਲਈ, ਇੱਕ ਮੌਜੂਦਾ ਲੱਭੋ ਅਤੇ ਇੱਕ ਪਲੱਸ ਜੋੜੋ, ਇੱਕ PR ਬਣਾਓ, ਜਾਂ ਸਿਰਫ਼ ਪ੍ਰੋਜੈਕਟ ਦੇ ਵਿਕਾਸ ਨੂੰ ਦੇਖੋ।

PS

ਸਾਡੇ ਬਲੌਗ 'ਤੇ ਵੀ ਪੜ੍ਹੋ:

• «ਪੇਸ਼ ਕਰ ਰਿਹਾ ਹਾਂ werf 1.0 ਸਥਿਰ: GitOps ਦਾ ਇਸ ਨਾਲ ਕੀ ਲੈਣਾ ਦੇਣਾ ਹੈ, ਸਥਿਤੀ ਅਤੇ ਯੋਜਨਾਵਾਂ»
• «werf - ਕੁਬਰਨੇਟਸ ਵਿੱਚ CI / CD ਲਈ ਸਾਡਾ ਟੂਲ (ਸੰਖੇਪ ਅਤੇ ਵੀਡੀਓ ਰਿਪੋਰਟ)";
• werf ਵਿੱਚ ਨਵੀਨਤਾਵਾਂ ਬਾਰੇ ਨੋਟਸ ਦੀ ਇੱਕ ਲੜੀ:
  • «3-ਵੇਅ ਮਰਜ ਟੂ ਵਰਫ: ਹੈਲਮ ਦੇ ਨਾਲ ਕੁਬਰਨੇਟਸ ਦੀ ਤੈਨਾਤੀ “ਸਟੀਰੌਇਡਜ਼ ਉੱਤੇ”";
  • «ਗੁੰਝਲਦਾਰ ਹੈਲਮ ਚਾਰਟ ਨੂੰ ਰੋਲ ਆਊਟ ਕਰਨ ਲਈ werf ਦੀ ਵਰਤੋਂ ਕਰਨਾ";
  • «ਵਰਫ ਵਿੱਚ ਮੋਨੋਰੇਪੋ ਅਤੇ ਮਲਟੀਰੇਪੋ ਲਈ ਸਮਰਥਨ ਅਤੇ ਡੌਕਰ ਰਜਿਸਟਰੀ ਦਾ ਇਸ ਨਾਲ ਕੀ ਲੈਣਾ ਦੇਣਾ ਹੈ";
  • «ਤੁਸੀਂ ਹੁਣ ਇੱਕ ਨਿਯਮਤ ਡੌਕਰਫਾਈਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਡੌਕਰ ਚਿੱਤਰਾਂ ਨੂੰ ਵਰਫ ਵਿੱਚ ਬਣਾ ਸਕਦੇ ਹੋ".

ਸਰੋਤ: www.habr.com