DSCI/posts/rakulang_ci.md at main · melezhik/DSCI · GitHub
//blob/show" data-turbo-transient="true" />
Skip to content
Search or jump to...
Search code, repositories, users, issues, pull requests...
-->
Search
Clear
Search syntax tips
Provide feedback
--><br>We read every piece of feedback, and take your input very seriously.
Include my email address so I can be contacted
Cancel
Submit feedback
Saved searches
Use saved searches to filter your results more quickly
-->
Name
Query
To see all available qualifiers, see our documentation.
Cancel
Create saved search
Sign in
//blob/show;ref_cta:Sign up;ref_loc:header logged out"}"<br>Sign up
Appearance settings
Resetting focus
You signed in with another tab or window. Reload to refresh your session.<br>You signed out in another tab or window. Reload to refresh your session.<br>You switched accounts on another tab or window. Reload to refresh your session.
Dismiss alert
{{ message }}
melezhik
DSCI
Public
Notifications<br>You must be signed in to change notification settings
Fork
Star<br>34
FilesExpand file tree
main
/rakulang_ci.md
Copy path
Blame<br>More file actions
Blame<br>More file actions
Latest commit
History<br>History<br>History
121 lines (88 loc) · 3.51 KB
main
/rakulang_ci.md
Copy path
Top
File metadata and controls<br>Preview
Code
Blame
121 lines (88 loc) · 3.51 KB
Raw<br>Copy raw file<br>Download raw file
Edit and raw actions
title<br>DSCI series / Rakulang CI
published<br>true
description<br>How to build CI pipelines for Rakulang using DSCI
tags<br>rakulang, ci, devops, automation
In this series I'm going to show how one can use DSCI to build CI/CD pipelines for various languages and stacks. And in today's episode we talk about Raku
Building Raku module usually involves installing dependencies and running unit tests:
.dsci/jobs.yaml
jobs:<br>id: ci<br>path: .
.dsci/task.bash
set -e<br>cd ../<br>ls -l<br>zef install . --deps-only<br>zef test .<br>echo "done"
In this simple Bash task we install module dependencies first and then run unit tests for the module. Easy step. Also zef and Raku is preinstalled on DSCI job runner, which makes things even easier for you.
Test coverage.
Say, we'd like run test coverage report to make it sure module has enough test coverage. We are going to use Test::Coverage (which excellently explained in Liz post ) for that. It's logical to add separate task that installs Test::Coverage first, before doing anything. Let's refactor out pipeline, as DSCI is just a tiny YAML layer and everything else is regular programming language, so it's easy to do that:
.dsci/job.raku - holds all the tasks executed for a job:
run_task "deps";<br>run_task "ci";
Tasks should reside under tasks/ folder, so we have two tasks:
.dsci/tasks/deps/task.bash
zef install --/test Test::Coverage
And .dsci/tasks/ci/task.bash modified (from .dsci/task.bash) to:
set -e<br>cd ../<br>ls -l<br>zef install . --deps-only<br>raku -I. xt/coverage.rakutest<br>echo "done"
When I run the pipeline against my dummy rakudist-teddy-bear module, I get these expected results:
= 80%'<br>09:59:18 :: # at xt/coverage.rakutest line 5<br>09:59:18 :: # You failed 1 test of 2<br>09:59:18 :: task exit status: 1<br>09:59:18 :: task . FAILED">09:59:18 :: All candidates are currently installed<br>09:59:18 :: # Failed test 'Coverage 33.33% >= 80%'<br>09:59:18 :: # at xt/coverage.rakutest line 5<br>09:59:18 :: # You failed 1 test of 2<br>09:59:18 :: task exit status: 1<br>09:59:18 :: task . FAILED
Switching on/off test coverage
Sometimes module author might want to disable running test coverage on their code, for example when you're contributing to someone's module adding some lines of code, but still have not done with new tests for them yet, DSCI allows to tune pipeline in many ways and one of the simplest method is to rely on commit messages. So, let's say if a committer add no_coverage string into commit message, then test coverage logic is disabled, let's modify the pipeline according to new requirements:
.dsci/job.raku:
unless $msg ~~ /no_coverage/ {<br>run_task "deps";<br>run_task "ci", %(<br>skip_coverage => ( $msg ~~ /no_coverage/ ?? True !! False )<br>);">my $msg = config();<br>unless $msg ~~ /no_coverage/ {<br>run_task "deps";<br>run_task "ci", %(<br>skip_coverage => ( $msg ~~ /no_coverage/ ?? True !! False )<br>);
And .dsci/tasks/ci/task.bash:
set -e<br>cd ../<br>ls -l<br>zef install . --deps-only<br>if test "$skip_coverage" = "True"; then<br>zef test .<br>else<br>raku -I. xt/coverage.rakutest<br>fi<br>echo "done"
That's it. Thanks for reading. Stay tuned for other languages and stacks examples. As one can see DSCI is extremely flexible and easy to work with as it's just a normal programming languages experience with a tiny YAML layer on top of it (to configure workflow). Combining the best of two worlds - declarative DSL and regular programming.
You can’t perform that action at this time.