Trying to understand Continuous Integration – The Sequel
I planned to write about gitlab runner this week but it seems like Adam has already covered it in his post
so no work for me, yay so I decided to make a sequel, or more accurately, an experiment.
As Adam said, to setup a runner, you must be admin. Thus I tried to make a dummy repo on gitlab to try it out. Turns out, when I go to the settings page, the shared runners are already enabled by default, and it seems like there’s no option to choose which runner to use.
So do I simply push a .yml file and the the runner will magically works just like that? Let’s find out!
First I made a python function in a file named
(because I’m not familiar with testing in ruby yet, let alone rails):
def run(s): return 'Run,'+s+', Run!'
and a unit test, named
class TestStringMethods(unittest.TestCase): def test_run(self): self.assertEqual(tes.run('Gitlab'), 'Run, Gitlab, Run!')
aand of course, the .yml:
before_script: - python -v - which python unittest: script: - python -m unittest test_tester
After I pushed them, something’s happening!
It’s okay, don’t panic, all according to keikaku*. Of course I deliberately missed a space there, it’s totally intentional. I did it to check what will happen if the test failed. Chill guys.
(In case you didn’t notice, there’s a missing space character in the return value of the
Anyways here’s what it looks like when not failing:
And I totally didn’t spent 15 minutes to fix one space. Honest!
- Seems like shared runners are enabled by default
- We only need to push a .yml file and everything will works automagically
- Just to make sure, once again, the bug was intentional. Believe me please 😦
*) TL note: keikaku means plan