All our executions allow you to add a comment, which you can provide when starting a process through our UI, via our API, or now even when initiating an execution using a webhook!
Simply include the header "Yep-Comment," and your comment will be stored.
Don’t forget, you can search for executions by their comments, making it easy to track status, results, or logs.
Run any business logic when a new message is received from the queue.
Check the docs for more details.
With the v3.0.0 version of YepCode CLI, we allow to install the dependencies that your team has configured in its workspace (see yepcode.io/docs/dependencies for docs).
We start to use ~/.yepcode folder to store both the login credentials and the installed dependencies.
This allows to add (and then push) a local created variable as sensitive.
Each YepCode process may have some input parameters that are defined with a JSON Schema. In our UI, form validation is always done, and now, with this new feature, you could also perform validations on webhooks or API invocations:
This is an infrastructure improvement that would fix some issues we are having with on-prem installations where the executor layers are killed by autoscaling cluster configurations.
This comes to improve the performance that the keywords search had.
You know that YepCode allows you to manage different versions of your processes and modules, so then you may start execution using an specific version of the source code.
This is great, but we wanted to go beyond... so we have introduced YepCode Version Aliases that are pointers to a process version that you can update with ease
This feature addresses the need to change the version used by an external service without deploying changes to that service.
Consider a scenario where an external service calls YepCode via a webhook, specifying a process version (e.g., v1.0) in the invocation header.
When you release a new process version (e.g., v2.0) and want to switch to it, updating the external service can be cumbersome. Instead, by using an alias in the webhook invocation (e.g., stable), initially linked to version v1.0, you can seamlessly transition to version v2.0 by simply updating the alias in the YepCode UI.
This approach eliminates the need to modify the external service, making version management more efficient
Version aliases can be used exactly in the same scenarios where process versions are available: run now, webhooks or scheduled configurations.
YepCode CLI now supports working with several remotes, being able for example to promote changes from staging workspace team to production workspace team.
Taking advantage of this, we have created a Github action that allows to do this using GIT as source code repository. Announcement here.
