The DebugReport is a global instance where steps can store information relevant for diagnosing failed pipelines. In the SDK Pipeline, this is used to generate a debug report within the postActionArchiveDebugLog step. The reason for adding this to Piper is to feed information about extended or overwritten stages in piperStageWrapper into the DebugReport, as was done before in the SDK Pipeline's equivalent runAsStage step.
* Enhance telemetry reporting
* Use central telemetry data object
* Add duration
Co-Authored-By: Christopher Fenner <26137398+CCFenner@users.noreply.github.com>
* add action to keep codebase up to date
* add go mod tidy command
* use official go action
* correct go fmt command
* fix code climate findings
* remove dummy changes
* separate checks
This is part of the effort to get rid of the "runAsStage" step in the SDK pipeline, and use piperStageWrapper directly. The SDK pipeline currently needs to support for loading "old" extensions where the call() method had different parameters. The support for the exact API can and should be removed, however, having a mechanism for supporting old extension APIs seems beneficial in general.
Another crucial change is the deleteDir() call before unstashing at the beginning of the stage. Without this, the SDK pipeline fails to unstash, since apparently the workspace may not always be clean at that point.
* add evaluateFromMavenPom to piper Utils
* adapt mavenExecute to accept `returnStdout` as parameter. If configured mavenExecute will return the stdout for further processing
* adapt tests of mavenExecute and mavenArtifactVersioning as well as add another exception to CommonStepsTest because mavenExecute will return a String if configured
* Fix random UUID generation in Unit Tests
* Use before and after methods
* Add import of org.junit.After
* Add go step for abapEnvironmentPullGitRepo
* Revert "Add go step for abapEnvironmentPullGitRepo"
This reverts commit 08b6b16217.
Co-authored-by: Oliver Feldmann <oliver.feldmann@sap.com>
On groovy level we take into account:
- parameters via signature
- project config
- landscape config(s)
- for docker: nested and plain config
also more tests added ...
In case docker parameters are configured in the project config or
in a landscape layer we have to take care. The corresponding values from
the context config are only the fallbacks.
* Use commonPipelineEnvironment in go binary
* Update groovy part incl. tests
* Rework structure and naming
* Support influx resources in steps
* Update tests and some cleanups
* Add correct defer handling
* Address PR feedback
* Fix test
* Update resources.go
Co-authored-by: Sven Merk <33895725+nevskrem@users.noreply.github.com>
* add evaluateFromMavenPom to piper Utils
* adapt mavenExecute to accept returnStdout as parameter. If configured mavenExecute will return the stdout for further processing (here grep'ing output of mvn help:evaluate)
* adapted the tests of mavenExecute and mavenArtifactVersioning as well as adding another exception to CommonStepsTest because mavenExecute will return a String if configured
