İthalat statik, içerik dinamik. İthalat, ayrıştırma sırasında gerçekleşir, çalışma zamanında içerir.
İthalat, temel olarak görevi dosyadaki görevlerle değiştirir. Çalışma import_taskzamanında yok . Bu nedenle, tagsve when(ve diğer olasılıklar gibi ) gibi nitelikler içe aktarılan her göreve kopyalanır.
includeGerçekten de idam edilir. tagsve whendahil olan bir görevin yalnızca görevin kendisi için geçerlidir.
importGörev etiketlenmemişse içe aktarılmış bir dosyadan etiketli görevler yerine getirilir. includeGörev etiketlenmemişse , hiçbir görev dahil edilen bir dosyadan yürütülmez .
importGörev etiketlenirse içe aktarılmış bir dosyadaki tüm görevler yerine getirilir. Yalnızca dahil edilen bir dosyadaki etiketli görevler, includegörev etiketlendiğinde yürütülür .
S sınırlamaları import:
with_*veya loopniteliklerle kullanılamaz- değişkene bağlı olan bir dosyayı alamıyor
S sınırlamaları include:
--list-tags dahil edilen dosyalardan etiket göstermiyor--list-tasks dahil edilen dosyalardaki görevleri göstermiyornotifydinamik bir içeriğin içinden gelen bir işleyici adını tetiklemek için kullanamazsınız--start-at-taskDinamik bir dahil içinde bir göreve yürütmeye başlamak için kullanamazsınız
Burada ve burada daha fazlası .
Benim için bu, temelde importdöngü öznitelikleriyle kullanılamaması gerçeğine bağlı .
importBu gibi durumlarda kesinlikle başarısız olur :
# playbook.yml
- import_tasks: set-x.yml
when: x is not defined
# set-x.yml
- set_fact
x: foo
- debug:
var: x
debugdevralır beri yürütülmez whengelen import_tasksgörevi. Yani, kullanılan değişkenleri değiştirmek hiçbir ithal görev dosyalar import'ın whenözelliğinde.
importS ile başlamak için bir politikam vardı , ancak bir keresinde includeiçerdiği dosya veya içerdiği dosyalar tarafından hiçbir şeyin içe aktarılmadığından emin olmak istiyorum. Ama bakımı oldukça zor. Ve hala beni sıkıntılardan koruyacak mı belli değil. Anlam, onların tavsiye etmediği karıştırma includes ve imports.
Sadece imports kullanamıyorum çünkü ara sıra includegörevlerim gerekiyor . Muhtemelen sadece includes'ye geçebilirim . Ancak görevin birkaç kez çalıştırılması gereken durumlar dışında her yere ithalat yapmaya geçmeye karar verdim. Tüm bu zor vakaları ilk elden deneyimlemeye karar verdim. Belki de oyun kitaplarımda hiç bir şey olmaz. Ya da umarım çalışmasını sağlayacak bir yol bulacağım.
UPD Birçok kez içe aktarılabilen ancak bir kez çalıştırılabilen bir görev dosyası oluşturmak için muhtemelen faydalı bir numara :
- name: ...
...
when: not _file_executed | default(False)
- name: ...
...
when: not _file_executed | default(False)
...
- name: Set _file_executed
set_fact:
_file_executed: True
UPD Karışımların ve ithalatların karıştırılmasının gerçekten beklenmeyen bir etkisi, ithal edilenleri geçersiz kılan varyasyonları içermesidir:
playbook.yml:
- hosts: all
tasks:
- import_tasks: 2.yml
vars:
v1: 1
- include_tasks: 2.yml
vars:
v1: 1
2.yml:
- import_tasks: 3.yml
vars:
v1: 2
3.yml:
- debug:
var: v1 # 2 then 1
Muhtemelen, çünkü include_tasksilk önce tüm statik ithalatları yapıyor, sonra da varsdirektiflerinden geçen değişkenleri değiştiriyor .
Aslında, sadece ithalatla olmaz:
playbook.yml:
- hosts: all
tasks:
- import_tasks: 2.yml
vars:
v1: 1
- include_tasks: 2.yml
vars:
v1: 1
2.yml:
- debug:
var: v1 # 2 then 1
vars:
v1: 2
UPD Başka bir karıştırma durumu, ithalatı içerir.
playbook.yml:
- hosts: all
tasks:
# here you're bound to use include, some sort of loop
- include_tasks: 2.yml
vars:
https: yes
2.yml:
- import_tasks: 3.yml
when: https
3.yml:
- import_tasks: 4.yml
vars:
https: no # here we're trying to temporarily override https var
- import_tasks: 4.yml
4.yml:
- debug:
var: https
Biz almak trueve true, yukarıda yer alan dava (vars ithalat vars önceliklidir dahil). Bu yüzden içine dahil etmeye geçiyoruz 3.yml. Ama sonra ilk ekleme 3.ymlatlanır. Çünkü when: httpsana görevin mirasını alır ve ikincisi sözde httpsgörevin görevinden alır vars. Çözüm, içerisine de geçmek 2.yml. Bu when: https, çocuk görevlerine yayılmasını önler .