The import
Statement
The import
statement allows you to import modules into your Cicada workflow.
Currently only
.ci
files inside the cloned repository can be imported, but a package manager and/or remote import mechanism will be added in the future.
To import files, type import
and then the filename you want to import:
import some/folder/file.ci
This will run some/folder/file.ci
and automatically make all its functions and variables
available via file.some_variable
.
Here is a full example of a workflow importing another module:
# module.ci
def greet(name: string):
echo Hello (name)!
# workflow.ci
on git.push
import module.ci
module.greet(event.author)
This workflow will, on git.push
, import module
, then greet the commit author.
Restrictions
There are some restrictions on how files are imported:
- The filename must include the
.ci
file extension. - The file must exist, otherwise the workflow fails.
- The filename must be a valid Cicada identifier. For example,
123
starts with a number, and thus would be invalid.
In addition, there are also restrictions on what imported modules are capable of:
-
Imported modules do not have access to the
secret
andenv
global variables. To pass a secret/env var to code in a module, you will need to do so explicitly via a function argument. This is for security reasons, since importing a malicious module (directly or indirectly) should not automatically expose sensitive data like your secrets. -
The
cache
,on
,run_on
, andtitle
statements are not usable in imported modules. This is because these statements only make sense when defined at the top level of a workflow. -
You cannot call functions annotated with
@workflow
in imported modules. Imported modules are still able to define functions annotated with@workflow
, but the modules themselves cannot call them. The reason being is that sub-workflows should be defined in the root of the workflow and not be hidden in a library function.