Following problem:

$ PYTHONPATH=$PWD scripts/spline --definition=examples/docker.yaml --tags=remove-docker-container
2018-08-16 05:50:04,315 - spline.application - Running with Python 2.7.13 (default, Nov 24 2017, 17:33:09) [GCC 6.3.0 20170516]
2018-08-16 05:50:04,321 - spline.application - Running on platform Linux-4.9.0-6-amd64-x86_64-with-debian-9.4
2018-08-16 05:50:04,321 - spline.application - Current cpu count is 4
2018-08-16 05:50:04,321 - spline.application - Processing pipeline definition 'examples/docker.yaml'
2018-08-16 05:50:04,339 - spline.application - Schema validation for 'examples/docker.yaml' succeeded
2018-08-16 05:50:04,382 - spline.tools.version - Using tool 'Bash', Version(4.4.12)
2018-08-16 05:50:04,382 - spline.tools.version - Using tool 'Docker', Version(17.12.1)
2018-08-16 05:50:04,383 - spline.tools.version - Using tool 'Spline', Version(1.11)
2018-08-16 05:50:04,383 - spline.components.stage - Processing pipeline stage 'example'
2018-08-16 05:50:04,384 - spline.components.tasks - Processing group of tasks (parallel=no)
2018-08-16 05:50:04,386 - spline.components.tasks - Processing Bash code: start
2018-08-16 05:50:04,397 - spline.tools.filters - render(syntax error): unexpected '.'
2018-08-16 05:50:04,398 - spline.components.tasks - Pipeline has failed: leaving as soon as possible!

The yaml contains {% raw %} and {% endraw %} which seems to be rendered twice and second time the remaining string contains {{.ID}} which cannot be resolved.

When I remove the recursive replace all is fine.

This patch permits the with option, of tasks, to contain Jinja2 renderable content. This is useful when the models section contains data to be reused across a number of tasks.

On the path to #63 (brainstorming: spline-server) my idea is to start as soon as possible using written functionality which is currently #64 (InMemoryFiles). With this I would like to introduce a new tool spline-stash that can store a path (recursively) at the stash-server and of course I would like to get back the content (usually on another location).

I still have to make my thoughts about the command line syntax but I'm a bit inspired by git stash of course. The server can run either locally or at a server; the only thing you would have to do is to install spline as usual and to run the server. For the moment no configuration is involved.

For the server I feel pretty comfortable (the moment) using Falcon (https://falconframework.org). I never used it before except running the given demo.

Considering that the pipeline uploads/deploys something this usually will happen on concrete branches only. As an example in some projects using Git the branch master is used as main line. Each time a pull request gets merged there a successful build should provide artifacts somewhere. The next task snippet could be the way to do it:

- shell:
    script: echo "upload"
    when: "{{ env.BRANCH_NAME }}" == "master"

When executing a Bash script the output of it is passed back the Python tool after completion which has two effects:

• for the time of execution of one Bash you see no output
• the logging of the lines of the output get wrong timestamps

It's not really a bug since the code does work.

This patch introduces automatic expansion of Jinja2 templates, except the Docker set-up related templates.

A direct benefit of this patch is one's pipeline configuration becomes less complex; with many Jinja2 render filters used everywhere becoming unnecessary.

Following problem:

FOO="\${}" spline
...
2018-06-13 15:15:08,595 - spline.components.bash - Running script /tmp/pipeline-script-Kj8mAR.sh
2018-06-13 15:15:08,612 - spline.components.tasks -  | /tmp/pipeline-script-Kj8mAR.sh: line 24: FOO=${}: bad substitution
2018-06-13 15:15:08,612 - spline.components.bash - Exit code has been 1
...

Simple pipeline demo for that issue (as sufficient):

pipeline:
  - stage(demo):
      - tasks(ordered):
        - docker(container):
            script: |
              echo "hello"

As I were told it seems that docker run --rm -v $PWD:/mnt/host -it centos:7 bash -c "ls /mnt/host" has failed on OSX while using ${PWD} should have been working. The docker container template is required to be updated for it.

Because final scripts runs on temporary path Dockerfile commands like ADD are not able to fetch content from the source path.

It turns out that providing the source path wouldn't help because Docker doesn't allow access to path outside the context (relative to the path where the build process is running)

• embedded solution
• generator for one environment (inventory, group_vars, playbook)
• dev, qa, or prod via model
• script section is playbook
• no roles
• updating the presentation

• Automatically organize mount and environment variable when ssh agent is active only.
• Basic procedure: -v $SSH_AUTH_SOCK:/ssh-agent --env SSH_AUTH_SOCK=/ssh-agent

Bumps wheel from 0.29.0 to 0.38.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps wheel from 0.29.0 to 0.38.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

This PR was automatically created by Snyk using the credentials of a real user.

Snyk has created this PR to fix one or more vulnerable packages in the `pip` dependencies of this project.

Changes included in this PR

• Changes to the following files to upgrade the vulnerable dependencies to a fixed version:
  • requirements.txt

sphinxcontrib-inheritance 0.9.0 has requirement Sphinx<=1.4.9, but you have Sphinx 1.6.5.
Sphinx 1.6.5 requires Pygments, which is not installed.
astroid 1.6.6 requires lazy-object-proxy, which is not installed.

Vulnerabilities that will be fixed

By pinning:

Severity | Priority Score (*) | Issue | Upgrade | Breaking Change | Exploit Maturity :-------------------------:|-------------------------|:-------------------------|:-------------------------|:-------------------------|:------------------------- | 441/1000
Why? Recently disclosed, Has a fix available, CVSS 3.1 | Regular Expression Denial of Service (ReDoS)
SNYK-PYTHON-SETUPTOOLS-3113904 | setuptools:
39.0.1 -> 65.5.1
| No | No Known Exploit

(*) Note that the real score may have changed since the PR was raised.

Some vulnerabilities couldn't be fully fixed and so Snyk will still find them when the project is tested again. This may be because the vulnerability existed within more than one direct dependency, but not all of the affected dependencies could be upgraded.

Check the changes in this PR to ensure they won't cause issues with your project.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.

For more information: 🧐 View latest project report

🛠 Adjust project settings

📚 Read more about Snyk's upgrade and patch logic

Learn how to fix vulnerabilities with free interactive lessons:

🦉 Regular Expression Denial of Service (ReDoS)

Snyk has created this PR to fix one or more vulnerable packages in the `pip` dependencies of this project.

Changes included in this PR

• Changes to the following files to upgrade the vulnerable dependencies to a fixed version:
  • requirements.txt

sphinxcontrib-inheritance 0.9.0 has requirement Sphinx<=1.4.9, but you have Sphinx 1.6.5.

Vulnerabilities that will be fixed

By pinning:

Severity | Priority Score (*) | Issue | Upgrade | Breaking Change | Exploit Maturity :-------------------------:|-------------------------|:-------------------------|:-------------------------|:-------------------------|:------------------------- | 661/1000
Why? Recently disclosed, Has a fix available, CVSS 7.5 | Out-of-bounds Read
SNYK-PYTHON-PILLOW-1292150 | Pillow:
6.2.2 -> 8.2.0
| No | No Known Exploit | 661/1000
Why? Recently disclosed, Has a fix available, CVSS 7.5 | Out-of-bounds Read
SNYK-PYTHON-PILLOW-1292151 | Pillow:
6.2.2 -> 8.2.0
| No | No Known Exploit

(*) Note that the real score may have changed since the PR was raised.

Some vulnerabilities couldn't be fully fixed and so Snyk will still find them when the project is tested again. This may be because the vulnerability existed within more than one direct dependency, but not all of the effected dependencies could be upgraded.

Check the changes in this PR to ensure they won't cause issues with your project.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.

For more information: 🧐 View latest project report

🛠 Adjust project settings

📚 Read more about Snyk's upgrade and patch logic

Snyk has created this PR to fix one or more vulnerable packages in the `pip` dependencies of this project.

Changes included in this PR

• Changes to the following files to upgrade the vulnerable dependencies to a fixed version:
  • requirements.txt

sphinxcontrib-inheritance 0.9.0 has requirement Sphinx<=1.4.9, but you have Sphinx 1.6.5.

Vulnerabilities that will be fixed

By pinning:

Severity | Priority Score (*) | Issue | Upgrade | Breaking Change | Exploit Maturity :-------------------------:|-------------------------|:-------------------------|:-------------------------|:-------------------------|:------------------------- | 661/1000
Why? Recently disclosed, Has a fix available, CVSS 7.5 | Denial of Service (DoS)
SNYK-PYTHON-PILLOW-1090584 | Pillow:
6.2.2 -> 8.2.0
| No | No Known Exploit | 661/1000
Why? Recently disclosed, Has a fix available, CVSS 7.5 | Denial of Service (DoS)
SNYK-PYTHON-PILLOW-1090586 | Pillow:
6.2.2 -> 8.2.0
| No | No Known Exploit | 661/1000
Why? Recently disclosed, Has a fix available, CVSS 7.5 | Denial of Service (DoS)
SNYK-PYTHON-PILLOW-1090587 | Pillow:
6.2.2 -> 8.2.0
| No | No Known Exploit | 661/1000
Why? Recently disclosed, Has a fix available, CVSS 7.5 | Denial of Service (DoS)
SNYK-PYTHON-PILLOW-1090588 | Pillow:
6.2.2 -> 8.2.0
| No | No Known Exploit

(*) Note that the real score may have changed since the PR was raised.

Some vulnerabilities couldn't be fully fixed and so Snyk will still find them when the project is tested again. This may be because the vulnerability existed within more than one direct dependency, but not all of the effected dependencies could be upgraded.

Check the changes in this PR to ensure they won't cause issues with your project.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.

For more information: 🧐 View latest project report

🛠 Adjust project settings

📚 Read more about Snyk's upgrade and patch logic

Snyk has created this PR to fix one or more vulnerable packages in the `pip` dependencies of this project.

Changes included in this PR

• Changes to the following files to upgrade the vulnerable dependencies to a fixed version:
  • requirements.txt

sphinxcontrib-inheritance 0.9.0 has requirement Sphinx<=1.4.9, but you have Sphinx 1.6.5.
Sphinx 1.6.5 requires Pygments, which is not installed.

Vulnerabilities that will be fixed

By pinning:

Severity | Priority Score (*) | Issue | Upgrade | Breaking Change | Exploit Maturity :-------------------------:|-------------------------|:-------------------------|:-------------------------|:-------------------------|:------------------------- | 661/1000
Why? Recently disclosed, Has a fix available, CVSS 7.5 | Denial of Service (DoS)
SNYK-PYTHON-PYGMENTS-1088505 | Pygments:
2.5.2 -> 2.7.4
| No | No Known Exploit

(*) Note that the real score may have changed since the PR was raised.

Some vulnerabilities couldn't be fully fixed and so Snyk will still find them when the project is tested again. This may be because the vulnerability existed within more than one direct dependency, but not all of the effected dependencies could be upgraded.

Check the changes in this PR to ensure they won't cause issues with your project.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.

For more information: 🧐 View latest project report

🛠 Adjust project settings

📚 Read more about Snyk's upgrade and patch logic