GitHub Actions to test simple code.

[smiths]

Following from #7, the next step is to setup a very simple GitHub action. I would like to get the infrastructure for this setup early.

Please do the following:

• create a new branch
• create a src folder in the new branch
• write a simple Julia module that implements linear interpolation - let's say you give it two points ((x, y) pairs) and an x value, and it returns the corresponding y value (calculated using linear interpolation)
• write a unit test for your linear interpolation module
• run the unit test using GitHub actions for every pull request
• create a pull request with your linear interpolation module to merge it in to main

The Julia module isn't intended to be something we use in the long run. It is just a simple thing we can do to set up the infrastructure. This is us "bootstrapping" our infrastructure. Once we get it so that this works, we will try to have it so that main always passes our continuous integration tests.

[EmilSoleymani]

Coding the linear interpolation was very quick. The hard part has been figuring out GitHub actions, and how to use it to run unit tests on my Julia code. I have been following this tutorial. I needed to add SSH keys and secrets, so I have been doing this work on a practice repository on my account where I have access to adding those. I have finally successfully created my first actions, and ran the first test! The test was simply evaluating the statement true but it will indeed be testing on every push to master branch of my repository. Now I must figure out some test cases for my linear interpolation module.
I might have a hard time replicating this process for our repository.

[smiths]

Thank you for the update @EmilSoleymani. If replicating is difficult in our repository because of permissions, just let me know what to do, and I'll do it. I haven't set up GitHub Actions myself, but I know a grad student that I'm sure would be happy to help us with some advice if we need it.

[EmilSoleymani]

Test cases for module complete. All tests passed. Repository can be found here. Beginning work on integration into our existing repository.

[smiths]

Looks good @EmilSoleymani. (Remember to add .DS_Store to your .gitignore file.) 😄

[EmilSoleymani]

@smiths Quick question. If I am working on some local files and I execute:

git init
git add .
git checkout -b [branchname]

If I now say git remote add origin [our repo] and then git push --set-upstream origin [branchname] will my files be successfully pushed to my specified branch leaving our master branch untouched?

In my plan to implement the CI with GitHub Actions I had to remake a vdisp folder with Julia's generate package functionality, then follow the steps in that video again. I will add our other folders/files as soon as I get these local ones onto a different branch in our repo.

Furthermore, will we only be running unit tests on pull requests, or should we add that functionality for each push as well.

[smiths]

Is it a security concern to publicly post these keys?

[EmilSoleymani]

Are these comment threads public? I have deleted the comment. I think an email would be the better route

[smiths]

Yes, our repo is public. Thank you for addressing this so quickly.

[smiths]

For #8 (comment):

Yes, your instructions look good. I think you already sorted that out. A resource I didn't mention previously is our git instructions on the Drasil repo. They are specific to the Drasil project in a few places, but for the most part, they work for any project.

[EmilSoleymani]

Thank you, I will check that out. Also, I was wondering if the keys were added so I can push my changes.

[smiths]

The first step didn't work. The error message is "Key is invalid. You must supply a key in OpenSSH public key format". I'll look into it, but if you have any ideas, that would be great too. 😄

[EmilSoleymani]

After all my copy-pasting a character or two might have been lost, I will send another email where I copy directly from the terminal output that gave me these keys.

[smiths]

Sounds good

[smiths]

The new keys worked. 😄

[EmilSoleymani]

GitHub actions have worked successfully!

Snippet of terminal output upon running my test cases

I had the code setup to run tests on every push just so I could see it working on this initial push. Would you like me to get rid of that functionality and have the tests only run on pull requests?

[smiths]

Great! On my other projects we run the tests only on pull requests, but let's try for a bit where we run the tests on every push. In the long run the tests will probably be too time consuming, and we'll need to worry about our free minutes on the GitHub CI server, but I don't think we are there yet. Having the test on every push will help build good habits.

[EmilSoleymani]

If we have limited free minutes then I don't think it is worth the tests on each push. Even this simple set of 4 tests on a linear interpolation function takes about 90 seconds since it has to setup the Julia environment each time

[smiths]

The number of minutes is fairly generous, but I agree that we don't want to run out. Let's do as you suggest and only test on each pull request. The coder can always run the test cases themselves in advance of each push.

Are you ready to do a pull request for the wip-julia-ci branch?

[EmilSoleymani]

Yes I have just updated the runtests action to not run on pushes. I will now do a pull request.

[smiths]

Great!

[EmilSoleymani]

I seem to be a little stuck, I don't see a button where I can submit the request

[smiths]

The problem is that your branch has a different commit history to main. This discussion might help:

https://stackoverflow.com/questions/23344320/there-isnt-anything-to-compare-nothing-to-compare-branches-are-entirely-diffe

[EmilSoleymani]

Pull request submitted, tests automatically executed as desired.