Why is my Anaconda prompt modifier showing the full environment path? - windows

I modified my anaconda environment directories. Any environments installed in the alternative directories show their full path in the prompt modifier. I am expecting only the name of the environment. Why is the full path showing up? Is this only aesthetic or will other things be affected?
Typically when creating an environment using anaconda prompt and the command:
>conda create -n my_env
I activate the environment using:
conda activate my_env
and the prompt changes from (base) to:
(my_env)>
I wish to share environments between users on the same machine. Following https://conda.io/projects/conda/en/latest/user-guide/configuration/use-condarc.html#specify-env-directories I added a file .condarc to the base conda install path containing:
#
envs_dirs:
- C:\Users\Public\CondaEnvs
Creating a new environment in the same way when I activate this environment I now see:
(C:\Users\Public\CondaEnvs\my_shared_env)
When the environment is active the environment variable CONDA_PROMPT_MODIFIER has also been set to (C:\Users\Public\CondaEnvs\my_shared_env).
The current output of conda config --show is:
add_anaconda_token: True
add_pip_as_python_dependency: True
aggressive_update_packages:
- ca-certificates
- certifi
- openssl
allow_conda_downgrades: False
allow_cycles: True
allow_non_channel_urls: False
allow_softlinks: False
always_copy: False
always_softlink: False
always_yes: None
anaconda_upload: None
auto_activate_base: True
auto_update_conda: True
bld_path:
changeps1: True
channel_alias: https://conda.anaconda.org
channel_priority: flexible
channels:
- defaults
client_ssl_cert: None
client_ssl_cert_key: None
clobber: False
conda_build: {}
create_default_packages: []
croot: C:\Users\ClibbonA\conda-bld
custom_channels:
pkgs/main: https://repo.anaconda.com
pkgs/free: https://repo.anaconda.com
pkgs/r: https://repo.anaconda.com
pkgs/msys2: https://repo.anaconda.com
pkgs/pro: https://repo.anaconda.com
custom_multichannels:
defaults:
- https://repo.anaconda.com/pkgs/main
- https://repo.anaconda.com/pkgs/free
- https://repo.anaconda.com/pkgs/r
- https://repo.anaconda.com/pkgs/msys2
local:
debug: False
default_channels:
- https://repo.anaconda.com/pkgs/main
- https://repo.anaconda.com/pkgs/free
- https://repo.anaconda.com/pkgs/r
- https://repo.anaconda.com/pkgs/msys2
default_python: 3.7
deps_modifier: not_set
dev: False
disallowed_packages: []
download_only: False
dry_run: False
enable_private_envs: False
env_prompt: ({default_env})
envs_dirs:
- C:\Users\Public\CondaEnvs
- C:\Users\ClibbonA\.conda\envs
- C:\ProgramData\Anaconda3\envs
- C:\Users\ClibbonA\AppData\Local\conda\conda\envs
error_upload_url: https://conda.io/conda-post/unexpected-error
extra_safety_checks: False
force: False
force_32bit: False
force_reinstall: False
force_remove: False
ignore_pinned: False
json: False
local_repodata_ttl: 1
migrated_channel_aliases: []
migrated_custom_channels: {}
non_admin_enabled: True
notify_outdated_conda: True
offline: False
override_channels_enabled: True
path_conflict: clobber
pinned_packages: []
pip_interop_enabled: False
pkgs_dirs:
- C:\ProgramData\Anaconda3\pkgs
- C:\Users\ClibbonA\.conda\pkgs
- C:\Users\ClibbonA\AppData\Local\conda\conda\pkgs
proxy_servers: {}
prune: False
quiet: False
remote_connect_timeout_secs: 9.15
remote_max_retries: 3
remote_read_timeout_secs: 60.0
report_errors: None
rollback_enabled: True
root_prefix: C:\ProgramData\Anaconda3
safety_checks: warn
sat_solver: pycosat
shortcuts: True
show_channel_urls: None
solver_ignore_timestamps: False
ssl_verify: True
subdir: win-64
subdirs:
- win-64
- noarch
target_prefix_override:
track_features: []
update_modifier: update_specs
use_index_cache: False
use_local: False
verbosity: 0
whitelist_channels: []

According to the conda documentation, you need to use the command conda config --set env_prompt "({name}) " (use double quotes on windows). Following these instructions, I found that when I deactivate the environment, the prepended string doesn't read (base) , but (Anaconda3) . That's a bit inconsistent with what people report, but maybe it's a windows thing. Just like the double quotes :p
Elsewhere on Stackoverflow someone has looked into the whole thing a bit and shown a few commands which sort of allow to circumvent this problem, although it's not very convenient to keep having to enter them. Based on the answers in that thread, I pieced together the following solution which did the trick for me:
Let's assume you created a virtual environment called myenv. Place a .condarc file in its directory (i. e., <current directory>\myenv\.condarc). The content of the file should be env_prompt: "({default_env}) " (plus other entries relevant to your project).
If you don't already have a general .condarc file, create one using the command conda config --set env_prompt "({name}) " with a whitespace after the closing parenthesis if you so desire. If such a file exists already, it should contain the line env_prompt: "({name}) ".
Now start your conda console. The environment prompt initially shows (Anaconda3) , but as soon as you activate and deactivate your virtual environment, everything's displayded the way it's supposed to. The command conda env list always displays the asterisk next to the correct environment when myenv is activated.

Have you tried:
conda activate env_name
Or
source activate env_name
? This commands should activate your environment(s) and you shouldn't have whole url path in your running program.
env_name
is the name of your environment.
You may try too this one:
conda config --set changeps1 False
You have to restart the command prompt after that, i.e. run your program in another window.

Related

GrumPHP and php-cs-fixer on WSL using wrong version

I'm trying to get GrumPHP to work with a small Laravel 9 project but php-cs-fixer is being pulled from the wrong location and I can't seem to find how to change this.
Error from GrumPHP:
phpcsfixer
==========
PHP needs to be a minimum version of PHP 7.1.0 and maximum version of PHP 7.4.*.
You can fix errors by running the following command:
'/windir/f/wamp64/vendor/bin//php-cs-fixer' '--config=./home/testuser/php-cs-config.php_cs' '--verbose' 'fix'
Seems like an easy fix, so I updated php-cs-fixer and followed the upgrade guide to get to v3. (currently sitting on 3.10). But I can also see that '/windir/f/wamp64/vendor/bin//php-cs-fixer' is not the correct directory for php-cs-fixer, the actual bin folder is located in WSL not the windows directory so I included a GRUMPHP_BIN_DIR in the grumphp yaml but still no luck.
grumphp.yml
grumphp:
environment:
variables:
GRUMPHP_PROJECT_DIR: "."
GRUMPHP_BIN_DIR: "./home/testuser/tools/vendor/bin/"
paths:
- './home/plustime/tools'
tasks:
phpcsfixer:
config: "./home/testuser/php-cs-config.php_cs"
allow_risky: ~
cache_file: ~
rules: []
using_cache: ~
config_contains_finder: true
verbose: true
diff: false
triggered_by: ['php']
I can't seem to find much about this or anything in the docs, so any help would be appreciated.
This ended up coming down to altering how WSL constructs the environment. To get around WSL building windows paths into the Linux distribution.
The answer was found here:
How to remove the Win10's PATH from WSL
Quick run down:
On the WSL instance open the file /etc/wsl.conf with something like
sudo nano /etc/wsl.conf
Add the following lines to the bottom of the file,
[interop]
appendWindowsPath = false
Mine looked like this when it was finished:
# Enable extra metadata options by default
[automount]
enabled = true
root = /windir/
options = "metadata,umask=22,fmask=11"
mountFsTab = false
# Enable DNS – even though these are turned on by default, we'll specify here just to be explicit.
[network]
generateHosts = true
generateResolvConf = true
[interop]
appendWindowsPath = false
Then restart the WSL instance from your windows terminal and restart it.
wsl --shutdown
GrumPHP now using the correct php-cs-fixer.

Modiyfing conda configuration file does not reflect changes in environment

I am trying to change the default installation location for Conda environments because the system I am using (a supercomputing cluster) has a ~20GB user home quota. Under normal circumstances, this could easily be done by editing ~/.condarc and adding a portion envs_dirs, which is explained quite well in this question and answer.
However, it seems that the compute environment I am in (i.e., with the supercomputer), does not let me modify the priority of various locations for environments. In an ideal world, I would be able to place /work/helikarlab/joshl/.conda/envs at the top of the list, which is a high-storage partition, so I can install additional environments if needed.
My ~/.condarc is configured as follows:
env_prompt: ({name})
channels:
- conda-forge
- bioconda
- defaults
auto_activate_base: false
envs_dirs:
- /work/helikarlab/joshl/.conda/envs/
Yet, I observe the following entries with conda config --show envs_dirs
envs_dirs:
- /home/helikarlab/joshl/.conda/envs
- /util/opt/anaconda/deployed-conda-envs/packages/python/envs
- /util/opt/anaconda/deployed-conda-envs/packages/perl/envs
- /util/opt/anaconda/deployed-conda-envs/packages/git/envs
- /util/opt/anaconda/deployed-conda-envs/packages/nano/envs
- /work/helikarlab/joshl/.conda/envs
- /home/helikarlab/joshl/.conda/envs/base_env/envs
Does anyone know why my attempt set envs_dirs is not working? How can I set the /work/helikarlab/joshl/.conda/envs to the highest priority?
Additional Info
Here is the result from conda config --show-sources
==> /util/opt/anaconda/4.9.2/.condarc <==
allow_softlinks: False
auto_update_conda: False
auto_activate_base: False
notify_outdated_conda: False
repodata_threads: 4
verify_threads: 4
execute_threads: 2
aggressive_update_packages: []
pkgs_dirs:
- ${WORK}/.conda/pkgs
- ${HOME}/.conda/pkgs
channel_priority: disabled
channels:
- hcc
- https://conda.anaconda.org/t/<TOKEN>/hcc
- conda-forge
- bioconda
- defaults
- file:///util/opt/conda_repo
==> /home/helikarlab/joshl/.condarc <==
auto_activate_base: False
env_prompt: ({name})
envs_dirs:
- /work/helikarlab/joshl/.conda/envs/
channel_priority: disabled
channels:
- conda-forge
- bioconda
- defaults
==> envvars <==
envs_path:
- /home/helikarlab/joshl/.conda/envs
- /util/opt/anaconda/deployed-conda-envs/packages/python/envs
- /util/opt/anaconda/deployed-conda-envs/packages/perl/envs
- /util/opt/anaconda/deployed-conda-envs/packages/git/envs
- /util/opt/anaconda/deployed-conda-envs/packages/nano/envs
Background: Conda's configuration priorities
As documented in "The Conda Configuration Engine for Power Users" post, Conda sources configuration values from four sources, listed from lowest to highest priority:
Default values in the Python code
.condarc configuration files (system < user < environment < working directory)
Environment variables (CONDA_* variables)
Command-line specifications
Problem: Environment variable prioritized
We can observe how this plays out in OP's case, with the --show-sources result. Specifically, there are three places where envs_dirs is defined:
System level configuration file at /util/opt/anaconda/4.9.2/.condarc
User-level configuration file at /home/helikarlab/joshl/.condarc
Environment variable CONDA_ENVS_PATH1
And since the environment variable takes priority and defines the preferred directory to be /home/helikarlab/joshl/.conda/envs, that will take precedence no matter what is set with conda config and .condarc files.
Workarounds
All the following workarounds involve manipulating the environment variable. It is unclear when the variable is set (probably via a system-level shell configuration file). It should be reliable to manipulate the variable by appending any of the following workarounds to user-level shell configuration file (e.g., ~/.bashrc, ~/.bash_profile, ~/.zshrc).
Option 1: Unset variable
One could completely remove the variable with
unset CONDA_ENVS_PATH
This would then allow the user-level .condarc to take priority.
However, this variable also appears to provide locations for several system-level shared environments. It is unclear how integral these shared environments are for normal functionality. So, removing the variable altogether could have additional consequences.
Option 2: Replace value
Conveniently, the location default and desired locations differ only by replacing /home with /work. This could be changed directly in the variable with:
export CONDA_ENVS_PATH=${CONDA_ENVS_PATH/\/home/\/work}
Option 3: Prepend desired default
The most general override would be to prepend the desired default path to the environment variable:
export CONDA_ENVS_PATH="/work/helikarlab/joshl/.conda/envs/:${CONDA_ENVS_PATH}"
This is probably the most robust, since it assumes nothing about the inherited value.
Additional Note
Users with small disk quotas in default locations should also consider moving the package cache (pkgs_dirs) to coordinate with the environments directory. Details in this answer.
[1]: CONDA_ENVS_DIRS and CONDA_ENVS_PATH are interchangeable, however only one can be defined at time. The former is the contemporary usage, so I believe the latter is likely supported for backward compatibility.

gitlab-runner unable to use `pyenv, pip, ...`

I am in the Debian9. And sudo su to become root user. After that I run the command gitlab-runner register. But for some reasons. I got the isolated environment not the same like when I login to the server over ssh
gitlab-runner --version
Version: 10.8.0
Git revision: 079aad9e
Git branch:
GO version: go1.8.7
Built: 2018-05-22T03:24:56+00:00
OS/Arch: linux/amd64
When I put env in the before_script I found the different environment.
Then I put source ~/.bashrc to it. Also does not make any change.
How to let shell runner use my normal login user environement?
Update:
When I execute env (by putting in before_script) I got this output
$ env
CI_RUNNER_EXECUTABLE_ARCH=linux/amd64
CI_COMMIT_TITLE=add config
CI_JOB_TOKEN=xxxxxxxxxxxxxxxxxxxx
CI_BUILD_REF_NAME=master
CI_REGISTRY_PASSWORD=xxxxxxxxxxxxxxxxxxxx
CI_RUNNER_TAGS=provider, oauth, mp
CI_SHARED_ENVIRONMENT=true
CI_JOB_NAME=test
CI_SERVER_VERSION=10.8.4
DJANGO_SETTINGS_MODULE=config.settings.local
LANG=en_US.UTF-8
GITLAB_CI=true
CI_SERVER_REVISION=2268d0c
CI_PROJECT_VISIBILITY=private
OLDPWD=/home/gitlab-runner
INVOCATION_ID=7dd516612949410c8ca8e4e59696f9fd
CI_COMMIT_SHA=9030892858b5ca92c7b36a81f573f187e6d14090
CI_COMMIT_MESSAGE=add config
CI_BUILD_STAGE=test
CI_PROJECT_URL=https://mbx-git.magicboxasia.com/sarit/mhu_ped_oauth_provider
CI_COMMIT_REF_SLUG=master
CI_SERVER_NAME=GitLab
CI_RUNNER_VERSION=10.8.0
CI_BUILD_NAME=test
CI=true
XDG_SESSION_ID=c5
CI_REGISTRY_USER=gitlab-ci-token
USER=gitlab-runner
CI_PROJECT_ID=96
CI_PIPELINE_ID=4399
CI_COMMIT_DESCRIPTION=
PWD=/home/gitlab-runner/builds/f304ea76/0/sarit/mhu_ped_oauth_provider
GITLAB_FEATURES=
HOME=/home/gitlab-runner
JOURNAL_STREAM=8:19161
CI_REGISTRY=docker-registry.magicboxasia.com
CI_BUILD_TOKEN=xxxxxxxxxxxxxxxxxxxx
CI_BUILD_ID=5514
CONFIG_FILE=/etc/gitlab-runner/config.toml
GITLAB_USER_NAME=Sarit Ritwirune
CI_PROJECT_PATH_SLUG=sarit-mhu-ped-oauth-provider
DATABASE_URL=postgres://postgres:postgres#postgres:5432/mp_oauth_provider
POSTGRES_DB=poinkdb
GITLAB_USER_EMAIL=sarit#magicboxasia.com
CI_COMMIT_REF_NAME=master
CI_REGISTRY_IMAGE=docker-registry.magicboxasia.com/sarit/mhu_ped_oauth_provider
CI_SERVER_TLS_CA_FILE=/home/gitlab-runner/builds/f304ea76/0/sarit/mhu_ped_oauth_provider.tmp/CI_SERVER_TLS_CA_FILE
CI_RUNNER_ID=42
CI_SERVER=yes
CI_JOB_ID=5514
CI_REPOSITORY_URL=https://gitlab-ci-token:xxxxxxxxxxxxxxxxxxxx#mbx-git.magicboxasia.com/sarit/mhu_ped_oauth_provider.git
MAIL=/var/mail/gitlab-runner
SHELL=/bin/bash
GITLAB_USER_LOGIN=sarit
CI_RUNNER_REVISION=079aad9e
CI_CONFIG_PATH=.gitlab-ci.yml
CI_PROJECT_NAME=mhu_ped_oauth_provider
POSTGRES_PASSWORD=postgres
POSTGRES_USER=postgres
SHLVL=2
CI_RUNNER_DESCRIPTION=MP OAuth Provider
CI_PROJECT_PATH=sarit/mhu_ped_oauth_provider
LOGNAME=gitlab-runner
XDG_RUNTIME_DIR=/run/user/999
GITLAB_USER_ID=39
CI_BUILD_BEFORE_SHA=e36e718d09f89095972ddf60ebf1fc1931282ae4
CI_BUILD_REF=9030892858b5ca92c7b36a81f573f187e6d14090
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
CI_PIPELINE_SOURCE=push
CI_PROJECT_NAMESPACE=sarit
CI_PROJECT_DIR=/home/gitlab-runner/builds/f304ea76/0/sarit/mhu_ped_oauth_provider
CI_JOB_STAGE=test
CI_BUILD_REF_SLUG=master
_=/usr/bin/env
$ python -V
Python 2.7.13
I am not sure this is the best practice or not, but I directly set the PATH by this in order to let the gitlab-runner use same as I do when ssh remote to server. But at least it works.
variables:
PATH: "/home/gitlab-runner/.pyenv/plugins/pyenv-virtualenv/shims:/home/gitlab-runner/.pyenv/shims:/home/gitlab-runner/.pyenv/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
Similar to setting variables directly in gitlab-ci ...
job:
variables:
MY_CUSTOM_VARIABLE:my_variable
Better place an environment file in your project's main directory within e.g a file .ci/env.
In project directory (same level as .gitlab-ci.yml):
$ mkdir .ci
$ vi .ci/env
Then, in .gitlab-ci.yml copy the file into build context:
before_script:
- . .ci/env
In there you can place your custom or modified variables as in:
Any custom variables
export MY_CUSTOM_VARIABLE=my_variable
Pyenv and pipenv context variables:
export PYENV_ROOT="$HOME/.pyenv"
export PATH=/home/gitlab-runner/.pyenv/shims:/home/gitlab-runner/.pyenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
export PIPENV_PYTHON="$PYENV_ROOT/shims/python"

How can we use environment variables in a Jekyll config file?

Is there a way I can use one my bash environment variable (say $FOO) in my Jekyll's _config.yml file?
I've tried using:
foo = <%= ENV['FOO'] %>
But it didn't work as the Ruby code wasn't interpreted.
Versions used:
Ruby: 2.1.2
Jekyll: 2.5.3
If your goal is to use environment variables as liquid items {{ site.something }}, you might be able to get this thing in your Gemfile a go:
gem 'jekyll-environment-variables', group: :jekyll_plugins
And then you'll be able to use {{ site.env.HOME }} and expect it be converted to something like /home/ubuntu in the output HTML.
Disclosure: I am the owner of the gem and I've been using it personally since long ago.
The answer by #elryco is close but not quite right, at least for my setup. It took some trial and error, but this finally worked. Note this only works for certain env vars supported by the contentful plugin.
Note that you need the gem jekyll-contentful-data-import (v1.7.0 or up) for this solution to actually work.
Bash environment (e.g., ~/.bash_profile):
export CONTENTFUL_ACCESS_TOKEN=foo
export CONTENTFUL_SPACE_ID=bar
In _config.yml, reference them as:
contentful:
spaces:
- example:
space: ENV_CONTENTFUL_SPACE_ID
access_token: ENV_CONTENTFUL_ACCESS_TOKEN
This is the same as what's written in the Github documentation.
I recently had to try and do this myself. It turns out you can't put environment variables directly into a Jekyll config file, but you can write a rake task that will take environment variables and apply them to your config.
Here's an example:
# Rakefile
require 'jekyll'
task default: %w[build]
desc "Build the site"
task :build do
config = Jekyll.configuration({
url: ENV["SITE_URL"],
})
site = Jekyll::Site.new(config)
Jekyll::Commands::Build.build(site, config)
end
Unfortunately there is no direct way of accessing it in liquid tags, At Least not officially.
But I wrote a wrapper script which reads environment variables before jekyll starts and appends it to _config.yml file and deletes the variable post build.
echo "secret-variable: $PASSWORD" >> _config.yml
bundle exec jekyll build -d target
sed '$d' _config.yml //this is to delete the last line
Now I'm free to use site.secret-variable anywhere in the liquid tags.
I know that this not the right way of doing it, But so is writing a custom ruby script.
I personally find the use of a ruby Jekyll plugin more appropriate and portable. There's a very simple yet effective solution available here.
The main idea is ruby will have access to the ENV variables so you can use a small ruby plugin to load into your site.config liquid array all the information you want from the environment. And you can define default values as well.
Please note that the example given in the link isn't the most relevant since the prod/staging environment is already offered by Jekyll natively with the build command options.
It is now possible to use bash environment variable (say $FOO) in Jekyll's _config.yml file with GitHub Actions:
# _config.yml
title: FOO
Create a bash script say sample.sh to replace for a given input string FOO and replace with another string
# github/workflows/sample.sh
export FOO=XYZ
while IFS='' read -r a; do
echo "${a//FOO/$FOO}"
done < /_config.yml > /_config.yml.t
mv /_config.yml{.t,}
Create a workflow file, say github-pages.yml, put the script before Build with Jekyll:
# Sample workflow for building and deploying a Jekyll site to GitHub Pages
name: Deploy Jekyll with GitHub Pages dependencies preinstalled
on:
# Runs on pushes targeting the default branch
push:
branches:
- 'master'
- 'mybranch'
# Allows you to run this workflow manually from the Actions tab
workflow_dispatch:
# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
permissions:
contents: read
pages: write
id-token: write
# Allow one concurrent deployment
concurrency:
group: "pages"
cancel-in-progress: true
jobs:
# Build job
build:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout#v3
- name: Setup Pages
uses: actions/configure-pages#v2
- name: Utilize FOO
run: |
bash .github/workflows/sample.sh
- name: Build with Jekyll
uses: actions/jekyll-build-pages#v1
with:
source: ./
destination: ./_site
- name: Upload artifact
uses: actions/upload-pages-artifact#v1
# Deployment job
deploy:
environment:
name: github-pages
url: ${{ steps.deployment.outputs.page_url }}
runs-on: ubuntu-latest
needs: build
steps:
- name: Deploy to GitHub Pages
id: deployment
uses: actions/deploy-pages#v1
If your bash environment variables are declared like this
export ENV_ACCESS_TOKEN=xxxxx
export ENV_SPACE_ID=yyyyyy
You can get it like this in your config.yml
space: ENV_SPACE_ID # Required
access_token: ENV_ACCESS_TOKEN # Required

Keep Ansible DRY: How to avoid repeating variables?

Recently just started using Ansible and I have run into a problem. In one of my YAML structures I have defined something like this:
---
# file: main.yml
#
# Jenkins variables for installation and configuration
jenkins:
debian:
# Debian repository containing Jenkins and the associated key for accessing the repository
repo: 'deb http://pkg.jenkins-ci.org/debian binary/'
repo_key: 'http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key'
# Dependencies needed for Jenkins to run properly
dependencies:
- 'openjdk-7-jdk'
- 'git-core'
- 'curl'
port: 8080
# Installation directory
home: '/opt/jenkins'
# Path to the location of the main Jenkins-cli binary
bin_path: '{{jenkins.home}}/jenkins-cli.jar'
# Path to the location of the Jenkins updates file
updates_path: '{{jenkins.home}}/updates_jenkins.json'
Ansible gives me an error like this from a specific task:
"recursive loop detected in template string:
{{jenkins.home}}/updates_jenkins.json"
I've narrowed it down to the problem being with the fact bin_path and updates_path both refer to 'home'. Is there a way around this? It kind of sucks that I would need to define '/opt/jenkins' multiple times.
As far as I know that this is a limitation of jinja2 variables. it was working with the old ${} and broke since 1.4. I am not sure if they fixed that in 1.5.
My temp solution would be removing home from the "jenkins"
---
# file: main.yml
#
# Jenkins variables for installation and configuration
# Installation directory
jenkins_home: '/opt/jenkins'
jenkins:
debian:
# Debian repository containing Jenkins and the associated key for accessing the repository
repo: 'deb http://pkg.jenkins-ci.org/debian binary/'
repo_key: 'http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key'
# Dependencies needed for Jenkins to run properly
dependencies:
- 'openjdk-7-jdk'
- 'git-core'
- 'curl'
port: 8080
# Path to the location of the main Jenkins-cli binary
bin_path: '{{jenkins_home}}/jenkins-cli.jar'
# Path to the location of the Jenkins updates file
updates_path: '{{jenkins_home}}/updates_jenkins.json'
This should do it:
bin_path: "{{ jenkins['home'] }}/jenkins-cli.jar"

Resources