command `which` requires a dedicated OS package to be installed.
In case a Jenkins Master or Jenkins Slave Image does not contain `which`, although `docker` command is available the step took a wrong turn.
This removes the check using `which` since checking `docker ps` is sufficient.
It comes with an extension to executeDocker and executeDockerOnKubernetes to run sidecar containers.
This helps to execute Selenium tests using two Docker images:
1. Execution runtime for tests (e.g. node image)
2. Selenium instance which holds Selenium server + browser
* add documentation & some name cleanup
* include PR feedback
* add step documentation to structure
read yaml rule is a very frequently used rule. But having the rule in the common rules
means we cannot register text or files to that rule, which makes it less handy to work
with yaml files in the tests.
* Create executeDockerOnKubernetes.groovy
* Update dockerExecute.groovy
* Create SysEnvTest.groovy
* Update default_pipeline_environment.yml
* Update executeDockerOnKubernetes.groovy
* Create utils object
* update docker image
* Update mavenExecute.groovy
* Use pipeline-lib than piper
* Check container name
* Always change ownership to 1000
* Check for map
* Fix command
* Move chmod to docker execute
* Use generic name for the pod
* runAsPod has been added
* Return false if script has no k8smapping
* fix syntax error
* Null checks
* Returnn dockerImage name
* Check method body
* Return container name
* Cleanup echos
* Use runAsPod
* Rename step
* Use official jenkins JNLP agent image
* Construct containersMap
* Check if kubernetes plugin is active
* Support JaaS
* pass script object
* Move configuration to default section
* Use generic flag to check if running in k8s
* fix jnlp agent name
* Solve travis errors
* Improvements to config and changes to name of the method
* Improvements to config
* Fix type
* Rename stash config
* add import
* Fix map order
* Fix jnlp agent name
* cleanup config usage
* Check if config is enabled
* Use nested k8s mapping
* Support custom docker workspace and move flag to env
* Feature/k8s stage (#1)
* Use nested k8s mapping
* Support custom docker workspace and move flag to env
* Check dockerOptions value
* Support local execution
* Add tests for dockerExecute
* Move config to step and Fix tests
* Use step configuration while running as a pod
* Streamline parameter and config initialization
* Streamline parameter and tests
* Cleanup and align variable name
* Use default JNLP agent if one not defined in config
* Add tests for runInsidePod. Ensure lowercase container names.
* Improve tests and remove unused code block
* Fix permission issues
* Perform stashing and unstashing inside container
* Use custom jnlp agent due to user id restriction
* Fix tests after jnlp agent change
* Address review comments
* Initialize script to default value if null
* Address review comments
* Update exeception handling and documentation
* Improve documentation
* correct indent
* Link documents to the index page
* Merge containerExecute and dockerExecuteOnKuberenetes step and address comments.
* Update dockerExecute.md
* Update dockerExecuteOnKubernetes.md
* Update default_pipeline_environment.yml
* update documentation
* Update documentation. Use annotation for singleton
* Update DockerExecuteOnKubernetesTest.groovy
* Update dockerExecute.groovy
* Update dockerExecuteOnKubernetes.groovy
* Improve documentation and test case names
* neoDeploy: switch to chained ConfigurationHelper (#244)
* switch neoDeploy to chained ConfigurationHelper
* update imports
* Improve tests
* Address review comments
* Improve documentation
* made dockerImage non-mandatory parm, improved test
* add comment regarding userid assumption
Starting point for that refactoring: it turned out that the tests
was not independent. The DefaultValueCache which is a singleton
keeps the status over various tests. Success of test execution depends
on the order test execution.
We have now
* a dedicated rule for resetting the default value cache
* JenkinsConfiguration rule (which already provided facilities for
dealing with the configuration) has been replaced by a readYaml rule.
From the PipelineUnit test framework we get already a handler for
libraryResource, which is also part of the setup of the default
values.
* An auxiliar class which combines the
* JenkinsSetupRule (registers the lib)
* JenkinsReadYamlRule (provides facilities for Yaml parsing)
* JenkinsResetDefaultValueCacheRule (cleans up the DefaultValueCache)
into a rule chain. By using this rule chain we ensure that our
setup OK (piper lib registered, and default config can be setup in
a clean way).
We check
1.) if docker-workflow plugin is installed
2.) if docker itself is installed on the system hosting Jenkins
If one of the conditions is not fullfilled we try to execute
locally.
