* Enhance doku for mtaExtensionCredentials for cloudFoundryDeploy
* Error message starting with lower case
* Log entry in case a variable is not used.
* Be less strict when replacing placeholders
* Check the variable name since we use now regex
* fix error message in assert
* simplify check for not replaced placeholders
* report unresolved
* report updated
* test updated=false
* 'do not' instead of 'does not' (test name)
* wip
* content not shared between tests
* rework parameter docu
* fix missing trailing quotation mark in test content
* Adjust quantifier when looking for not replaced placeholders
* fmt
* Introduce transport request create solman
* log the transport request id also in case creation failed
maybe there are some rare cases where a transport request id is returned nevertheless.
* report exit code always
* inline parameter
* Provide more parameters in log message, might help with troubleshooting
Co-authored-by: Roland Stengel <r.stengel@sap.com>
These hints are up to now provided as javadoc like comments
at the call method for cloudFoundryDeploy step. At that level
they are not taken into account by the go generator.
Is is not a suitable approach to include this kind of markdown
docu into the long description of the metadata file since this
long description is (also) used by the piper help command when
invoking piper cloudFoundyDeploy --help. At that point in time
markdown like text does not make sense.
* Provide getters for stdout, stderr on ShellRunner, ExecRunner
we need that in order to set the streams back in case we have to scan the command
output ourselvs during some function calls.
* LogRange provide git log ref1..ref2
This we need for checking inside the commit range
for transportRequestIds and changeDocumentIDs in the
body of the commit message.
* LogRange provide git log ref1..ref2
This we need for checking inside the commit range
for transportRequestIds and changeDocumentIDs in the
body of the commit message.
* [refactoring] Make room for other upload action: move package
In the near future we will have more upload actions, like
SOLMAN, RFC. Here we prepare the package structure for that.
* don't use aliasing
* rename entities (no leading CTS)
With the current approach we get a failure when the generated
content triggers a change. But we cannot see what was changed.
With this commit we can see the diff. In case there is not diff
we will not see anything, so there is in that case no real change
in the behaviour. But in case there is a change we will see that
change.
Without that we have to reproduce locally, which means additional
efforts.
From the current location inside "cmd" the npmExecutorMock cannot
be used from any coding inside "pkg".
When we would like to re-use the npm functionality we have also to
provide tests and this requires having a mock.
In order to be able to use the mock from pkg we move the mock from
"cmd" to "pkg" into package "npm".
With the shift from package "cmd" to "npm" a lot of fields in the mock
has been made public.
Up to now we get a message 'Requested resource could not be found' which is not very
helpul during troubleshooting based on the log. With this change we tell the reader
which resource could not be resolved.
`piperExecuteBin` is called with a credentials list. Each list entry is a map consisting of
* the type of the credential (e.g. usernamePassword, token)
* the identifier which is used for resolving the credential.
* a list of environment variables which holds the resolved credentials.
Inside `piperExecuteBin` the id was resolved against the config and the result was used for resolving the credentials against the jenkins-credentials-plugin.
With this change here we introduce another key for the map mentioned above:
* resolveCredentialsId
When this key is provided with value `false` we do not resolve the credentials-id from the config. In that case the id is directly used for resolving the credential again the jenkins-credentials-plugin.
Up to now the code generator is not able to handle the type
map[string]interface{} which is important for nested
configurations.
With that change we support such nested configuration.
Fo now parameters with a map type are not supported via
command line parameters. Those parameters are simply
ommitted. But with this change is it possible to read
such nested structures from the pipeline configuration
(.pipeline/config.yml).
As a next step we can discuss if we would like to support
such values also via command line parameters. One possible
approach could be
```
./piper <command> -myParam key1=val1 --myParam key2=val2
```
which gets finally collected inside our map:
```
map["key1"] = "val1"
map["key2"] = "val2"
```
This is of course hard to do for deeper nestings. In that case
providing a pointer to a file might be more suitable.
In that context we need to consider how to
- declare the default values for map like parameters in our
metadata files.
- deal with the different types we have for the parameter
itself wrt the yaml like config on the one hand and on the
level of the command line parameters on the other hand. Maybe for
that we have to extend the metadata format (e.g. describe an
alternate type receiving the values from the command line, like
[]string. With that approach values for simple nested (... not deep
nested) params can be provided like described above, it would be
possible to represent these parameters for the command line parser
as string slice entries like "[]string{key1=val1, key2=val2". These
parameters needs in this case transformed "by us" into the map we
use further down the road.
In case we agree in principle on an approach as outlined here we should
adjust the golden files reflecting this use case.
Is there any benefit from having
```
assert.Error(./.)
assert.EqualError(./.)
```
?
assert.Error ensures that we have an error.
assert.EqualError ensures that we have an error and
moreover it checks for a specific error. Hence
assert.EqualError does all and more what assert.Error
does.
In case there is a benefit from that pattern this PR should not be merged.
In case there is not benefit from that pattern we should abandong that pattern.
* Avoid CPS serialization issue in setupCPE
When handing over an instance of SCMInfo we got a
CPS serialization issue. Hence we don't hand over
that instance any more
o git commit id is resolved with exising git tooling
o git branch is handed over as parameter to setupCPE
The approach used up to now did not (... never) work since the uploaded content was always assigned to the `$TMP` package. In the meanwhile there is some fiori tooling available for managing such uploads.
Now we re-use this fiori tooling.
Co-authored-by: Oliver Feldmann <oliver.feldmann@sap.com>
This reverts commit 32fd89c664.
Commit mentioned above has been merged in order to circumvent
the issue which has been resolved by commit 0a17ed56. Since this
issue is now resolved and since there is no other known use case
for running deployments explicitly in parallel we decided to remove
that flag again.
without 'int' in a 'for (i = 0; ...)' loop 'i' is
a global variable and the value gets inside some parallel
execution randomly incremented from the parallel threads.
Defining it with the keyword 'int' makes it a method local
variable which does not change its value 'randomly'.
Co-authored-by: Christopher Fenner <26137398+CCFenner@users.noreply.github.com>
* do not swallow exception triggered inside SWA handling
--> write it to the log
The real change is in src/com/sap/piper/Utils.groovy
All the changes in the tests are dealing with mocking the echo method
used in the Utils class mentioned above.
Vars file handling centralized
We have the same coding for handling varsf-files and vars. With that change we shift to having one common coding for that
the space does not contribute to the uniqueness of the lock
identifier. Hence the space should be removed.
Co-authored-by: Christopher Fenner <26137398+CCFenner@users.noreply.github.com>
Provide cloudFoundryDeploy step in GO layer.
Groovy part untouched. Groovy-Stub needs to be provided later (with a feature toggle in order to be able to switch back)
Co-authored-by: Stephan Aßmus <stephan.assmus@sap.com>
* Dont work upon a global command.Command instance inside cloudfoundry package
o Up to now we work on a private and shared instance of command.Command inside
the cloudfounrdy package. We need to be able either configure this instance
(environment variables) according to the use case. One option is to hand over
an already configured instance which is used elsewhere. This is what we do with
this commit.
o With this commit we remove the instance which is shared within the cloudfounrdy
package and to provide an instance with a receiver which gets handed over to the
functions. Hence we are thread save: parallel invoctation of e.g. Login will not
affect each other.
o Up to now we work on a private and shared instance of command.Command inside
the cloudfounrdy package. We need to be able either configure this instance
(environment variables) according to the use case. One option is to hand over
an already configured instance which is used elsewhere. This is what we do with
this commit.
o With this commit we remove the instance which is shared within the cloudfounrdy
package and to provide an instance with a receiver which gets handed over to the
functions. Hence we are thread save: parallel invoctation of e.g. Login will not
affect each other.
- mock is used now for cf api commands
- tests for cf api and cfk login are checking which
commands are really executed
- some minor simplifications wrt asserts
* [refactoring] move the shell/command related interfaces into pkg/command
otherwise we are not able to use the corresponding mocks for the items contained in pkg since
these interfaces are not visible from the pkg folder
Co-authored-by: Daniel Kurzynski <daniel.kurzynski@sap.com>
* Add capabilities for checks if a file has been written
With the current file system mock we cannot assert if
a file has been written. E.g. we cannot distiguish between
files added to the virtual file system before the test and files
explicitly written. In contrast to that we can check for deleted
files.
With the change here we get a func HasWritteFile(name).
[Q] Wouln't it be possible to check based on the file content
if a file has been written (the new file should have another
content as the file registered before).
[A] We should not assert some file content here since the
produced file content can be created by another "class" which
is unit tested somewhere else. With that approach we would test
the producer here again.
Co-authored-by: Stephan Aßmus <stephan.assmus@sap.com>
* Provide test for yamlUtils substitution with boolean value false
* Fix: handle booleans with value 'false' in yaml substitution
* Improve variable naming
Provide a timeout parameters to malwarescan step. This is forwarded to the piper http layer. The default used there is 10 seconds with is not useable for that use case for larger files.
* Include error in the log.
In case the default text formatter is used, the error
will be contained in the log, too.
* Avoid stupid nil token printed in error message
Marcus Hollandphgermanov
