Any way to check/test a .space.kts job locally before git push?
Beed doing lots of work on a job to build/test/deploy a .net + docker container, and many minor errors are only noticed after a git push and pipeline run. Is there any way to do a dry run or partial check on local machine before push? Thanks.
Please sign in to leave a comment.
Thank you for reaching out to us!
A job run can be triggered directly from the Space UI. To do this, you can click "Jobs" on the navigation bar, open the "All Runs" tab, and select the needed Job by its name. You can find the "Run" button at the top right corner. After clicking it, a job run will be triggered.
If I get your request right, this should be enough to test how the script or its job component works.
As for running a job from IDE, currently, it is not supported. The corresponding team has confirmed that they would like to add this feature but not in the nearest future. I have filed YT ticket below so you can track the updates on this request:
https://youtrack.jetbrains.com/issue/SPACE-18270/Triggering-a-job-run-directly-from-an-IDE
Please let me know if there is anything else I can help with.
Oleg Beriashvili
JetBrains
http://www.jetbrains.com
The Drive to Develop
I think you completely missed the point of the question. I do not want to trigger a remote run of the job from the IDE, but rather run the job in some simulation envrionment, or at least test the kts sytax check locally on my computer. This would avoid dozens tiny git commits to fix minor syntax errors, and trials of how to make the kotlin script dsl translate into desired bash script which take ~2 minutes each find. I'm sitting at ~25 already, that's an hour of waiting for these small changes to be sent up and attempted.
Also finding the kotlin script completely un-necessary & clunky to work with with it's odd syntax to handle envars in shell scripts which in my cases are required for almost everything. The pre-build "commands" don't ever quite handle what actually needs to be done, just plain old bash commands do. Also has to be parsed/checked and transformed prior to job run.
I would like to add weight to this comment as I too have wasted way too much time for simple automation jobs because of the same reasons.
Not only are there not enough real-world examples, but there is also no way to test and validate a .space.kts script before pushing it to the repository.
At this point there is no benefit, rather only downsides to migrating from Gitlab CI/CD or even Github Actions to this.
The purpose is to debug and validate script locally before pushing. When you integrate some new step/job in your CI/CD you spent most of the time pushing and waiting for remote server (self hosted or JB hosted to run the job). If script was updated first you wait some minutes for script validation and only after that job execution starts. Sometimes it takes several commits to make script fully valid and IJ doesn't catch things. Then you proceed with business logic updates and validations and tenth or even hundreds of other commits are added. Finally you lose time and your branch in some kind of commit hell. So you need to squash.