Steps

a step is a core building block of the microtica pipeline by chaining multiple steps, you can build complex pipelines to automate your entire software delivery process in microtica, there are two types of pipeline steps generic steps build in steps generic steps generic steps provide a flexible way to precisely define your step instructions and have a full control over what that step does microtica yaml steps mygenericstep image node\ latest title build my nodejs app commands \ npm install \ npm test in this step definition we have image – the docker image that defines the runtime environment title (optional) – a step description commands – a list of commands to be executed in this step in this example, we use the latest version of nodejs as our runtime environment and execute a set of npm commands in the same way, we can define a runtime environment for go language and compile the code microtica yaml steps mygostep image golang\ latest commands \ go build built in steps built in steps are steps provided by microtica for certain actions that are common when defining ci/cd pipelines some typical actions would be build/push docker images, executing terraform scripts or sending slack messages below is an example of using a built in step of type docker push that builds and pushes docker image on a specified docker registry microtica yaml steps pushdockerimage type docker push image name microtica/my app tag v0 1 0 registry my registry in this step definition we have type – the step type image name – the name of the image to be pushed tag – the tag identifier for the image registry – the name of the registry, created within microtica, to be used you can notice that we haven’t specified a runtime for our step or any custom commands to be executed everything happens automatically behind the scenes step parameters each built in step would have a different set of parameters which are specific for that step type under steps https //docs microtica com/steps you can find more information about individual built in steps input parameters input parameters allow the step to accept the input data that can be used inside the step execution using generic steps you can define an arbitrary number input parameters for your step use parameters when you want to parametrize the way you pipeline works avoid hard coding within the step execution logic avoid storing sensitive information within the pipeline yaml using pipeline variables https //docs microtica com/variables here is an example of providing a custom parameter to a step microtica yaml steps buildapp image node\ latest commands \ echo "build my service ${service name}" parameters service name "user service" parameters service name can be referenced in the commands section using a standard unix syntax ${service name} security consideration never hard code sensitive data in pipeline yaml for security reasons, always use pipeline variables with sensitive flag enabled when specifying parameters like passwords, secret tokens or any other data which is considered as sensitive sharing state between steps to enable seamless integration between steps, microtica provides automated state sharing between steps having this, you don’t have to worry about managing and maintaining the state manually each step within the pipeline shares the same directory state with the other steps allowing files generated in the current step to be automatically available in all following steps in the execution order sharing state between steps comes handy when you want to design your pipeline with multiple steps that need to share the same state a good example of this would be when you compile your code in one step and execute tests against previously compiled code in another step artifacts sharing state between steps is beneficial when you want to have the state persisted between steps however, in cases when you want the output of a certain step to be available outside of the pipeline, microtica allows you to do that by using artifacts here’s an example of producing an output artifact my artifact microtica yaml steps buildnodeapp image node\ latest commands \ npm install \ npm run build artifacts files \# wildcard are also supported in the path (e g /build/ js) my artifact /build/ in this case, the entire content within the build folder will be packaged, zipped and stored on a secure blob storage artifacts can be downloaded from the gui for each pipeline execution if more then one artifact is being declared, you can choose which one to download microtica also provides built in support for docker and json artifacts to learn more about all supported artifact types jump to artifacts spec https //docs microtica com/artifacts