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

Feature: Allow overwriting of 'gitlab_runner_install_directory' #339

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

nicoklaus15
Copy link
Contributor

Under Windows, it is a common practice to use different partitions or hard disks to prevent applications from overloading the main hard disk and crashing the system. GitLab Runner is also a good candidate to fill up the disk and crash the computer. Therefore, it would be helpful to install it on a separate hard disk, but at the moment this is not possible due to variable precedence.

https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_variables.html#understanding-variable-precedence

Therefore, the installation directory should be moved to the defaults and then this can be changed in the inventory for each host or globally.

@@ -11,6 +11,9 @@ gitlab_runner_wanted_version: latest
# This variable should not be modified usually as it depends on the gitlab_runner_wanted_version variable
gitlab_runner_wanted_tag: "{{ 'latest' if gitlab_runner_wanted_version == 'latest' else ('v' + gitlab_runner_wanted_version) }}"

# If a different partition or disk is used under Windows
gitlab_runner_install_directory: c:/gitlab-runner/
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess your problem is to not being able to override this particular variable? If so, this is true for all variables which are included with include_vars. Instead of moving variables from the platform specific files to this general one and pollute it that way, we should think of a (clever) way to make platform-specific variables also overridable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is a general problem for all variables in this file, as they only represent the “default”. But the location where I want to install something should be definable from my point of view, it would also be possible that Windows has no C: drive at all. Since Ansible has variable precedence, I don't think there will be a clever way around this, or maybe it shouldn't be implemented.

https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable

It's also not impossible to override the platform specific variables like the download URL, but in this case I have to override them for each host, which is not possible once the precedence is higher than the host_vars.

@guenhter sorry for the late reply, the notification passed me by :/

@shock0572
Copy link

One straight up solution that comes to the mind is specializing the default vars to windows_gitlab_runner_install_directory but he's right in a way: we don't want to have the Windows directory fixed and it's only used in the windows playbook

@nicoklaus15 nicoklaus15 changed the title Featuer: Allow overwriting of 'gitlab_runner_install_directory' Feature: Allow overwriting of 'gitlab_runner_install_directory' Sep 6, 2024
@guenhter
Copy link
Collaborator

I posted this to the ansible forum

https://forum.ansible.com/t/include-default-variables-based-on-conditions/8433/2

and there could be one interesting solution:

mysql_community_packages: "{{ lookup('ansible.builtin.vars', 'mysql_community_packages_' + os_version, default='mysql-server') }}"
mysql_community_packages_redhat9:
  - mysql
  - mysql-server
  - mysql-common

I'll give this a try when time and come back to you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants