Easy workflow file for setting up GitHub Actions CI for your Julia package

Thank you all for the really helpful tips. Can I double check the steps of the migration?

  1. Go to the repository or organization and create a DOCUMENTER_KEY secret
  2. Copy/paste the CI.yml file shared by @dilumaluthge inside .github/workflows
  3. Disable Travis CI in the repository or organization

Is it fine to disable Travis CI? I mean, can I just remove it from the list of authorized apps? Also, where is the GITHUB_TOKEN defined again? I couldn’t find this secret anywhere. Should I create this secret in the organization in case it doesn’t exist yet?

I am assuming that we still need Codecov enabled to get the coverage, we can’t remove it from the list of authorized apps, correct?

@Ronis_BR you created two separate actions one for stable Julia and another for nightly Julia because the latter can fail and you don’t care if it fails for merging PRs right? I like the idea. I wonder if there is a less brute force method to achieve the same result without having to copy two action files with the same contents basically. Anyone has suggestions?

I will try to trigger the new setup with a PR soon.

You can simply remove the .travis.yml file and Travis won’t run anyway. Anything else is unnecessary, but of course you’re free to do it

When else fails, read the documentation

Yes

1 Like

Yes, that’s exactly what I did. I searched a little bit if GitHub actions have an option to replace allow_failure of Travis but AFAIK it does not have anything that can replicate the behavior 100%.

1 Like

Thank you @Ronis_BR, I will end up doing the same, or just removing Julia nightly from the build. I actually don’t look at it these days. I only care about stable Julia. Nightly was important for me when Julia was at versions < 1.

1 Like

Thank you @giordano, I found out about GITHUB_TOKEN right after I submitted the question. :slight_smile:

For some reason, Documenter.jl is failing to decode the DOCUMENTER_KEY:

Can the value of the secret key be an arbitrary string or it has some restriction? I couldn’t find anything online for that one.

People helped on Zulip, we need to generate the value with:

using DocumenterTools
using MyPackage
DocumenterTools.genkeys(MyPackage)
1 Like

Does anyone know how to configure a configuration specific environment variable?
It seems that my attempt here failed https://github.com/FluxML/NNlib.jl/pull/246
(the ubuntu configuration with JULIA_NUM_THREADS: 2 was not spawn)

I also had difficulties setting environment variables in matrix.include, this is what I ended up doing in BinaryBuilderBase.jl:
https://github.com/JuliaPackaging/BinaryBuilderBase.jl/blob/573b396e475c05353ce9d975bd726774d59b8e39/.github/workflows/ci.yml#L19-L36
Instead this is what I do in LombScargle.jl to run tests with both 1 and 2 threads:
https://github.com/JuliaAstro/LombScargle.jl/blob/b4c1a98820713dfd9538047521e88940b8021596/.github/workflows/ci.yml#L14-L31

1 Like

thanks, that was helpful, It’s working now

1 Like

What’s the recommended way to set up a test status badge with this?

Silly me, it is documented.

1 Like

Question: older recommended setups (on Travis) had a test/coverage folder with a project file and a small script, like

get(ENV, "TRAVIS_OS_NAME", nothing)       == "linux" || exit(0)
get(ENV, "TRAVIS_JULIA_VERSION", nothing) == "1.5"   || exit(0)

using Coverage

cd(joinpath(@__DIR__, "..", "..")) do
    Codecov.submit(Codecov.process_folder())
end

That is no longer necessary if I am not using Travis?

How old is that? I’ve never seen this setup in any package

See eg

https://github.com/JuliaDocs/DocStringExtensions.jl/blob/5d7e09c1e5bfac6ff7dfafb5d6f0341c61a5abfc/test/coverage.jl

It kind of made sense on Travis I guess.

You could do something similar also for Github Actions, you need to change the environment variables, but this is definitely not the recommended way of doing code coverage for the last few years, not even in Travis since that was as easy as

codecov: true
coverrals: true

in the Travis script

2 Likes

There’s a script at https://github.com/julia-actions/MassInstallAction.jl/tree/master/demos/MaintenanceDec2020 that handles a lot of the necessary updates for you.

2 Likes

OK, I made the conversion from Travis to GA but I can’t make Documenter to work. The make.jl looks like this and work with Travis but errors in GA if I don’t comment line
https://github.com/GenericMappingTools/GMT.jl/blob/documenter-test/docs/make.jl#L6
and specially the one with
push_preview = true,
otherwise it errors with (and if I comment it the docs do not get updated)

Your Documenter version is way too old (see your docs/Project.toml).

1 Like

Right, thanks for looking (but that same one works with Travis).

Updated it and now no error but it also doesn’t update de docs.

https://github.com/GenericMappingTools/GMT.jl/runs/1742334165#step:5:67

┌ Error: Git failed to fetch git@github.com:GenericMappingTools/GMT.jl.git
│ This can be caused by a DOCUMENTER_KEY variable that is not correctly set up.
│ Make sure that the environment variable is properly set up as a Base64-encoded string
│ of the SSH private key. You may need to re-generate the keys with DocumenterTools.
└ @ Documenter ~/.julia/packages/Documenter/FuXcO/src/Documenter.jl:554
1 Like

Linux / Gtk.jl / xvfb-run

Does anyone know how to get things to work if you depend on Gtk.jl?

I tried adding xvfb-run as was done in Gtk.jl’s ci.yml - to no avail:
InspectDR.jl/ci.yml at master · ma-laforge/InspectDR.jl · GitHub

CI test fails due to the display for some reason.

Missing libgtk-3-dev maybe?

I also noticed that I my old .travis.yml file included:

addons:
  apt:
    packages:
      - libgtk-3-dev

But there is no such entry in Gtk.jl’s own ci.yml file since the migration to Github Actions.

Assistance would be greatly appreciated :slight_smile:.