Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tasks in an 'include_tasks' are not run when specifying tags (unlike the deprecated include) #30882

Closed
nilsfr opened this Issue Sep 25, 2017 · 26 comments

Comments

Projects
@nilsfr
Copy link

nilsfr commented Sep 25, 2017

ISSUE TYPE
  • Bug Report
COMPONENT NAME

ansible/lib/ansible/playbook/block.py

ANSIBLE VERSION
ansible 2.4.0.0
  config file = /home/nilsfr/.ansible.cfg
  configured module search path = [u'/home/nilsfr/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
  ansible python module location = /home/nilsfr/usit/vortex-vhostlib/venv-vhostlib-py2/local/lib/python2.7/site-packages/ansible
  executable location = /home/nilsfr/usit/vortex-vhostlib/venv-vhostlib-py2/bin/ansible
  python version = 2.7.12 (default, Jul  1 2016, 15:12:24) [GCC 5.4.0 20160609]
SUMMARY

The difference between 'include' and 'include_tags' is in this line:

(task.action == 'include' and task.evaluate_tags([], play_context.skip_tags, all_vars=all_vars)) or

Is this intentional?

In the project I am working on we are relying on the use of tags inside a dynamic include.

@ansibot

This comment has been minimized.

Copy link
Contributor

ansibot commented Sep 25, 2017

@nilsfr Greetings! Thanks for taking the time to open this issue. In order for the community to handle your issue effectively, we need a bit more information.

Here are the items we could not find in your description:

  • issue type
  • ansible version
  • component name

Please set the description of this issue with this template:
https://raw.githubusercontent.com/ansible/ansible/devel/.github/ISSUE_TEMPLATE.md

click here for bot help

@arbabnazar

This comment has been minimized.

Copy link
Contributor

arbabnazar commented Sep 26, 2017

@nilsfr can you please try import_tasks instead of include_tasks, I think that's the limitation of the include_tasks and it's mentioned somewhere in the docs.

@nilsfr

This comment has been minimized.

Copy link
Author

nilsfr commented Sep 26, 2017

I use it in a loop, so I cannot use import_tasks. I also tried to tag the loop with 'always', but then all the tasks inside was run regardless of their tags.

Example:

- include_tasks: "vhost.yaml"
  vars:
    vhost_vars: "{{ vhosts_vars[vhost] }}"
  with_items: "{{ vortex_vhosts }}"
  loop_control:
    loop_var: vhost
@arbabnazar

This comment has been minimized.

Copy link
Contributor

arbabnazar commented Sep 26, 2017

@nilsfr you didn't mentioned about the loop in your issue report. You can read about the include_tasks and tags here

@nilsfr

This comment has been minimized.

Copy link
Author

nilsfr commented Sep 26, 2017

The way I read the documentation it says that tags added to an import_tasks will be added to all tasks that are imported, but tags added to an include_tasks will only apply to the task itself. I cannot read from this that the whole include_tasks should be skipped if itself to not have the required tag. It should look into the imported file and dynamically check each task for the tag, that is if it do not have any tags on itself. This is how 'include' currently behaves.

If I add an 'always' tag to the include_tasks all the tasks inside will always run, which it the opposite from what I read from the documentation.

If you change the the expression in above mentioned line to, it will work:

(task.action in ('include', 'include_tasks') and task.evaluate_tags([], play_context.skip_tags, all_vars=all_vars))

@jborean93 jborean93 removed the needs_triage label Sep 28, 2017

@froebela

This comment has been minimized.

Copy link

froebela commented Oct 19, 2017

We also hit the same issue. We heavily use dynamic task includes (combined with loops) and tags inside included tasks in order to limit the execution of tasks. Hence the new module "include_tasks" should also evaluate tags inside included tasks as the deprecated module "include" did. Otherwise the module "include_tasks" would be unusable for us.

We now want to go one step further and use dynamic role includes using the module "include_role". We performed some tests and hit the same issue there as well. So it would be nice, if the module "include_role" could be included in the problem resolution too.

@djadk84

This comment has been minimized.

Copy link

djadk84 commented Nov 10, 2017

Not being able to use include and tags will pretty damaging to all my playbooks, I use a lot of loops and variables. This makes my transition to include_tasks impossible for now. Let's hope you guys give us a better alternative.

@vbohata

This comment has been minimized.

Copy link

vbohata commented Nov 28, 2017

Same for me. I still have to use old include because include_tasks does not support tags.

@lfventura

This comment has been minimized.

Copy link

lfventura commented Nov 29, 2017

Same here. We are not able to migrate our playbooks due to the lack of tag support that was present before.

@krzysztof-magosa

This comment has been minimized.

Copy link
Contributor

krzysztof-magosa commented Dec 14, 2017

The same issue here.
I understand that it may be some form of optimisation, but would be fine to be able to bypass it and run include so it can scan underlying tags.

@ocervell

This comment has been minimized.

Copy link

ocervell commented Dec 18, 2017

Same ...

@pari-

This comment has been minimized.

Copy link
Contributor

pari- commented Jan 7, 2018

Hi,

reading the documentation:

When it comes to Ansible task options like tags and conditional statements (when:):

For static imports, the parent task options will be copied to all child tasks contained within the import.
For dynamic includes, the task options will only apply to the dynamic task as it is evaluated, and will not be copied to child tasks.

To me, it effectively says, that tagged include_tasks-tasks are not skipped, but dynamically evaluated at runtime (in contrast to include previously). Now if none of these 'dynamically included'-tasks are tagged as well, none will be run.

An example:

test.yml:

---

- hosts: "localhost"
  tasks:
    - include_tasks: "tasks/include_tasks.yml"
      tags:
        - "first"

tasks/include_tasks.yml:

---

- debug:
    msg: "first include_tasks"
  tags:
    - "first"

- debug:
    msg: "second include_tasks"
  tags:
    - "second"

ansible-playbook test.yml -t second:

PLAY [localhost] ******************************************************************************************************************************

TASK [Gathering Facts] ************************************************************************************************************************
ok: [localhost]

PLAY RECAP ************************************************************************************************************************************
localhost                  : ok=1    changed=0    unreachable=0    failed=0

ansible-playbook test.yml -t first:

PLAY [localhost] ******************************************************************************************************************************

TASK [Gathering Facts] ************************************************************************************************************************
ok: [localhost]

TASK [include_tasks] **************************************************************************************************************************
included: /Users/pringl/development/ansible/tasks/include_tasks.yml for localhost

TASK [debug] **********************************************************************************************************************************
ok: [localhost] => {
    "attempts": 1,
    "msg": "first include_tasks"
}

PLAY RECAP ************************************************************************************************************************************
localhost                  : ok=3    changed=0    unreachable=0    failed=0

ansible-playbook test.yml -t first,second:

PLAY [localhost] ******************************************************************************************************************************

TASK [Gathering Facts] ************************************************************************************************************************
ok: [localhost]

TASK [include_tasks] **************************************************************************************************************************
included: /Users/pringl/development/ansible/tasks/include_tasks.yml for localhost

TASK [debug] **********************************************************************************************************************************
ok: [localhost] => {
    "attempts": 1,
    "msg": "first include_tasks"
}

TASK [debug] **********************************************************************************************************************************
ok: [localhost] => {
    "attempts": 1,
    "msg": "second include_tasks"
}

PLAY RECAP ************************************************************************************************************************************
localhost                  : ok=4    changed=0    unreachable=0    failed=0

To me, this works as documented. What am I missing?

Thanks,
pari

@mauricios

This comment has been minimized.

Copy link

mauricios commented Jan 9, 2018

@pari- I'm having different results than you using the same example files.

When I run ansible-playbook test.yml -t first I get:

PLAY [localhost] ********************************************************************************************************************************************************

TASK [Gathering Facts] **************************************************************************************************************************************************
ok: [localhost]

TASK [include_tasks] ****************************************************************************************************************************************************
included: /Users/user/test_tags/tasks/include_tasks.yml for localhost

TASK [debug] ************************************************************************************************************************************************************
ok: [localhost] => {
    "msg": "first include_tasks"
}

TASK [debug] ************************************************************************************************************************************************************
ok: [localhost] => {
    "msg": "second include_tasks"
}

PLAY RECAP **************************************************************************************************************************************************************
localhost

If I add the tag to the include_tasks task and try to run only the tagged tasks Ansible will execute all tasks inside the included file.

I'm using:
OS: macOS High Sierra
ansible 2.4.2.0
python version = 2.7.14

@pari-

This comment has been minimized.

Copy link
Contributor

pari- commented Jan 9, 2018

@mauricios you're right. The behaviour changed with ebf971f:

commit ebf971f931290a113f738f658d7a6e095994e120
Author: James Cammarata <jimi@sngx.net>
Date:   Fri Jan 5 20:51:44 2018 -0600

    Don't use getattr in _get_parent_attribute to avoid recursion issues (#33595)

    * Don't use getattr in _get_parent_attribute to avoid recursion issues

    Fixes #23609

    * Move extend/prepend to field attribute

    Also removes _get_attr* methods that were basically just calling
    _get_parent_attribute because it needed to set those params.

    Also modifies _get_parent_attribute() to pull those values from the
    FieldAttributes instead of using the ones passed into the function.

    * Better fixes for _get_parent_attribute

I was using devel when trying to reproduce this and I totally forgot about testing it with the version the bugreport was supplied with, though! :-)

@magykjames

This comment has been minimized.

Copy link

magykjames commented Feb 23, 2018

Same issue here. include_tasks is totally unusable since tags within the included playbooks are ignored and we're using with_items to loop over extra-vars for each included playbook.

We're using Ansible for VM deployments, where the same playbook is used to create the VM and then perform actions on it after it builds (like reconfigure or destroy). With include_tasks, the VM gets destroyed and re-built every time the playbook runs! Cloud scale I guess, right? Just re-create everything every time?

@ansibot ansibot added bug and removed bug_report labels Mar 1, 2018

@dhiratgithub

This comment has been minimized.

Copy link

dhiratgithub commented Mar 31, 2018

Hi Everyone,

Please take a look into below issue (include_tasks not working with --tags) -

[root@ansiblecontrolnode tags]# cat inventory
[servers]
ansiblemanagednode.example.com
[databases]
ansiblemanagednode.example.com

[root@ansiblecontrolnode tags]# ansible --version
ansible 2.4.2.0
config file = /root/ANSIBLE/Chapter5/tags/ansible.cfg
configured module search path = [u'/root/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
ansible python module location = /usr/lib/python2.7/site-packages/ansible
executable location = /usr/bin/ansible
python version = 2.7.5 (default, Aug 4 2017, 00:39:18) [GCC 4.8.5 20150623 (Red Hat 4.8.5-16)]

[root@ansiblecontrolnode tags]# cat demonstrationtags.yml

    - name: Install Database packages
      yum:
            name: "{{ item }}"
            state: latest
      with_items: "{{ db_packages }}"
      tags: dev
      notify: start_db

    - name: Get small config file
      get_url:
            url: "{{  db_config_src_path_small }}"
            dest: "{{  db_config_path }}"
      when: db_config_src_path_small is defined
      notify: restart_db
      tags: dev

    - name: Get large config file
      get_url:
            url: "{{  db_config_src_path_large }}"
            dest: "{{  db_config_path }}"
      when: db_config_src_path_large is defined
      notify: restart_db
      tags: prod

    - name: Update motd for development
      copy:
            content: "This is a develeopment server"
            dest: /etc/motd
      tags: dev

    - name: Update motd for production
      copy:
            content: "This is a production server"
            dest: /etc/motd
      tags: prod

...
[root@ansiblecontrolnode tags]# cat demonstrationplaybook.yml

  • hosts: all
    gather_facts: no
    vars:
    db_packages:
    - mariadb-server
    - MySQL-python
    db_config_url: http://server1.example.com:/task_control
    db_config_src_path_small: "{{ db_config_url }}/my.cnf.small"
    db_config_src_path_large: "{{ db_config_url }}/my.cnf.large"
    db_config_path: /etc/my.cnf
    db_service: mariadb

    tasks:
    - name: Including demonstrationtags.yml
    include_tasks: demonstrationtags.yml
    when: inventory_hostname in groups['databases']

         handlers:
         - name: start_db
           service:
             name: "{{ db_service }}"
             state: started
    
         - name: restart_db
           service:
             name: "{{ db_service }}"
             state: restarted
    

...
[root@ansiblecontrolnode tags]# ansible-playbook demonstrationplaybook.yml --tags 'dev'
[DEPRECATION WARNING]: Specifying include variables at the top-level of the task is deprecated. Please see: http://docs.ansible.com/ansible/playbooks_roles.html#task-include-files-and-
encouraging-reuse for currently supported syntax regarding included files and variables. This feature will be removed in version 2.7. Deprecation warnings can be disabled by setting
deprecation_warnings=False in ansible.cfg.

PLAY [all] **************************************************************************************************************************************************************************************

PLAY RECAP **************************************************************************************************************************************************************************************

Why "demonstrationtags.yml" is not ebing called by "demonstrationplaybook.yml" when specifying with --tags ?

Thanks in advance!

thanks,
Dhirendra

@dhiratgithub

This comment has been minimized.

Copy link

dhiratgithub commented Mar 31, 2018

  • --list_tags outputs:

[root@ansiblecontrolnode tags]# ansible-playbook demonstrationplaybook.yml -vvv --list-tags
ansible-playbook 2.4.2.0
config file = /root/ANSIBLE/Chapter5/tags/ansible.cfg
configured module search path = [u'/root/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
ansible python module location = /usr/lib/python2.7/site-packages/ansible
executable location = /usr/bin/ansible-playbook
python version = 2.7.5 (default, Aug 4 2017, 00:39:18) [GCC 4.8.5 20150623 (Red Hat 4.8.5-16)]
Using /root/ANSIBLE/Chapter5/tags/ansible.cfg as config file
Parsed /root/ANSIBLE/Chapter5/tags/inventory inventory source with ini plugin
[DEPRECATION WARNING]: Specifying include variables at the top-level of the task is deprecated. Please see: http://docs.ansible.com/ansible/playbooks_roles.html#task-include-files-and-
encouraging-reuse for currently supported syntax regarding included files and variables. This feature will be removed in version 2.7. Deprecation warnings can be disabled by setting
deprecation_warnings=False in ansible.cfg.
1 plays in demonstrationplaybook.yml

playbook: demonstrationplaybook.yml

play #1 (all): all TAGS: []
TASK TAGS: []

Thanks,
Dhirendra

@Yajo

This comment has been minimized.

Copy link
Contributor

Yajo commented Apr 2, 2018

I'm affected too here. Let me expose some facts to everyone:

  1. I already had migrated all my playbook to {include/import}_tasks.

  2. It worked perfectly in Ansible 2.4.

  3. I understand the purpose of not delegating the tags by default: sometimes you need to perform dynamic includes, but if you filter through a tag, then everything inside include_tasks will be executed. There's no way for you to filter them.

    OTOH I understand the complaints, since most times, when I apply one tag to an include, I expect all its tasks to execute.

    We need some further control over this. Options:

    • include_tasks can have a delegate_tags attribute that when set to true delegates all tags to all of its tasks.
    • Or we could have a new syntax when running the playbook, such as --tags higher+, which means that include_* statements tagged with higher will be executed, with their subtasks too.
  4. include_tasks was clearly tagged as preview, so shame on me for migrating to that so soon 😿

  5. If include_tasks was called under a block that was tagged with some extra tags, those tags also don't appear in the included tasks. There's basically no way to tag included tasks, except putting all of them in a separate file that makes a static import and tags them (or in a block).

  6. include, OTOH, is flagged as deprecated:


    so now we must choose between:

    • Do not use Ansible 2.5
    • Use the deprecated include module Edit: I just tested switching include_tasks to include and it's suffering the exact same problem!
    • Use the unstable include_tasks module

Honestly we have been left in a not very desirable state... I hope that this can be fixed soon 😕

Thanks for this great tool and the work you're doing to improve it!

@Yajo

This comment has been minimized.

Copy link
Contributor

Yajo commented Apr 2, 2018

I have come to a workaround. I can safely change to import_tasks whenever there's no loop involved.

When there's one, given I had these:

outer.yaml
- tags:
  - tag_1
  - tag_2
  block:
    - include_tasks: inner.yaml
      tags: tag_3
      loop:
        - one
        - two
      loop_control:
        loop_var: myvar
inner.yaml
- debug:
    var: myvar

Now I have changed outer.yaml to include_tasks: import_inner.yaml, which has:

- import_tasks: inner.yaml
  tags:
    - tag_1
    - tag_2
    - tag_3

It's a 💩 but keeps the diff minimal, polluting only files that are outside normal git history, and that I hope will disappear soon when this gets fixed in Ansible 5.0.1 😁

davidfischer-ch added a commit to davidfischer-ch/ansible-roles that referenced this issue Apr 3, 2018

@jctanner jctanner added this to TODO in CEM Apr 11, 2018

@bcoca

This comment has been minimized.

Copy link
Member

bcoca commented Apr 11, 2018

So include had many 'magical' behaviors and we are trying to make them explicit and clear, at one point we added the ability to ignore 'specified' tags so we could run tasks depending on include tasks.
The behaviour you see is intentional, the new import_ and include_ were created to remove much of this magic and establish clear behaviors depending on which one is used.

  • import_ <- no keywords apply to it, it always happens and any keywords are inherited by contained
    tasks. So this will have the behaviour of ignoring tags on itself and NOT condition execution based on them.

  • include_ <- keywords apply to it and are NOT inherited by contained tasks. So this will NOT ignore tags and WILL condition it's execution based on them.

You can get mostly what include did with include_ by adding tags: ['always'] to ensure the include_ executes by default no matter what tags you specify. There are other workarounds using block or just going back to include which we want to eventually remove but not until all cases are covered by the new actions.

Another feature we plan, to help with include_ inheritance: #38262 (comment), which does not really affect this issue but does affect how you tag in general.

There are more differences between include_and import_ and you can read those at http://docs.ansible.com/ansible/latest/porting_guides/porting_guide_2.5.html#dynamic-includes-and-attribute-inheritance

Hope that explains and helps all.

@bcoca bcoca closed this Apr 11, 2018

@Yajo

This comment has been minimized.

Copy link
Contributor

Yajo commented Apr 12, 2018

Thanks for your answer. I didn't think about tagging it as always, but I guess it will do the trick for most cases.

About the inherit stuff, wow... That'd be awesome indeed.

@Canta

This comment has been minimized.

Copy link

Canta commented Apr 12, 2018

We've hit this hard, as we're using hundreds of dynamic includes with tags, and v2.5 gave us many silent fails and strange behaviours. So I did a very dirty script in order to "migrate" to the new dynamic include paradigm, wrapping our includes with blocks.

Still testing the results, as IDK if all of our hundreds of DIs work as expected, but so far the results are doing fine even for complex roles.

So, in case it could be useful for anyone, I've put it online, here: https://gist.github.com/Canta/8b44b84f8bb699f0a53840574e0d887e

Please, be careful before running that on your environment. A testing environment would be wise. And do check what it does, in case you need some different greps and stuff related to your environment.

@mkrizek mkrizek moved this from TODO to DONE in CEM May 9, 2018

@jinowolski

This comment has been minimized.

Copy link

jinowolski commented Jun 22, 2018

In case somebody finds it useful.

I've checked which tasks will run with include_tasks and import_tasks depending on tags.

Here are results for Ansible 2.5.2:

ansible 2.5.2
option: --tags t1
                      |CALLED TASK TAGS
CALLING TASK TAGS     |(none) t1     t2     t1+t2  always
----------------------+-----------------------------------
include_tasks  (none) | no    no     no     no     no
include_tasks  t1     | no    yes    no     yes    yes
include_tasks  t2     | no    no     no     no     no
include_tasks  t1+t2  | no    yes    no     yes    yes
include_tasks  always | no    yes    no     yes    yes
----------------------+-----------------------------------
import_tasks   (none) | no    yes    no     yes    yes
import_tasks   t1     | yes   yes    yes    yes    yes
import_tasks   t2     | no    yes    no     yes    yes
import_tasks   t1+t2  | yes   yes    yes    yes    yes
import_tasks   always | yes   yes    yes    yes    yes


option: --skip-tags t2
                      |CALLED TASK TAGS
CALLING TASK TAGS     |(none) t1     t2     t1+t2  always
----------------------+-----------------------------------
include_tasks  (none) | yes   yes    no     no     yes
include_tasks  t1     | yes   yes    no     no     yes
include_tasks  t2     | no    no     no     no     no
include_tasks  t1+t2  | no    no     no     no     no
include_tasks  always | yes   yes    no     no     yes
----------------------+-----------------------------------
import_tasks   (none) | yes   yes    no     no     yes
import_tasks   t1     | yes   yes    no     no     yes
import_tasks   t2     | no    no     no     no     no
import_tasks   t1+t2  | no    no     no     no     no
import_tasks   always | yes   yes    no     no     yes

What surprises me is that import_tasks ignores --tags, but respects --skip-tags. Is it intended?

Testing code - role tasks:

main.yml
---
# basic checks to be sure that the playbook is called as intented
- name: "main - no tags"
  debug:
    msg: "main - no tags"

- name: "main - t1"
  debug:
    msg: "main - t1"
  tags:
    - t1

- name: "main - t2"
  debug:
    msg: "main - t2"
  tags:
    - t2

- name: "main - t1,t2"
  debug:
    msg: "main - t1,t2"
  tags:
    - t1
    - t2

- name: "main - always"
  debug:
    msg: "main - always"
  tags:
    - always

# include_tasks calls
- name: "include_tasks - no tags"
  include_tasks: inner.yml

- name: "include_tasks - t1"
  include_tasks: inner.yml
  tags:
    - t1

- name: "include_tasks - t2"
  include_tasks: inner.yml
  tags:
    - t2

- name: "include_tasks - t1,t2"
  include_tasks: inner.yml
  tags:
    - t1
    - t2

- name: "include_tasks - always"
  include_tasks: inner.yml
  tags:
    - always

# import_tasks calls
- debug:
    msg: "importing with no tags"
  tags:
    - always

- name: "import_tasks - no tags"
  import_tasks: inner.yml

- debug:
    msg: "importing with t1"
  tags:
    - always

- name: "import_tasks - t1"
  import_tasks: inner.yml
  tags:
    - t1

- debug:
    msg: "importing with t2"
  tags:
    - always

- name: "import_tasks - t2"
  import_tasks: inner.yml
  tags:
    - t2

- debug:
    msg: "importing with t1,t2"
  tags:
    - always

- name: "import_tasks - t1,t2"
  import_tasks: inner.yml
  tags:
    - t1
    - t2

- debug:
    msg: "importing with always"
  tags:
    - always

- name: "import_tasks - always"
  import_tasks: inner.yml
  tags:
    - always
inner.yml
---
- name: "inner - no tags"
  debug:
    msg: "inner - no tags"

- name: "inner - t1"
  debug:
    msg: "inner - t1"
  tags:
    - t1

- name: "inner - t2"
  debug:
    msg: "inner - t2"
  tags:
    - t2

- name: "inner - t1,t2"
  debug:
    msg: "inner - t1,t2"
  tags:
    - t1
    - t2

- name: "inner - always"
  debug:
    msg: "inner - always"
  tags:
    - always
@sivel

This comment has been minimized.

Copy link
Member

sivel commented Jun 22, 2018

The major differences between include_tasks and import_tasks as it relates to tags is that:

  • Tags applied to include_tasks only apply to the include_tasks task, and not the tasks within.
  • Tags applied to import_tasks are inherited by the tasks within.

import_tasks is a preprocessor, and effectively ansible replaces the import_tasks task with the list of tasks that are imported.

If you have further questions please stop by IRC or the mailing list:

@keitalbame

This comment has been minimized.

Copy link

keitalbame commented Nov 9, 2018

Just got "bit" by this and noticed that if one uses block, the task is now included.

- block:
    - include_tasks: your_tasks.yml
      with_items: "{{ some_item }}"
  tags: your_tag
@deoren

This comment has been minimized.

Copy link

deoren commented Nov 19, 2018

@sivel
The major differences between include_tasks and import_tasks as it relates to tags is that:

  • Tags applied to include_tasks only apply to the include_tasks task, and not the tasks within.
  • Tags applied to import_tasks are inherited by the tasks within.

import_tasks is a preprocessor, and effectively ansible replaces the import_tasks task with the list of tasks that are imported.

Request: Expand your saved response to also include what appears (#34196 (comment)) to be a requirement that the outer include_ also be tagged, that this tag be provided with the --tags option along with the tags for used by applicable included tasks in order for those tasks to run. If I'm correct, then this info would be really useful for others that come across this and related GitHub issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.