Thanks! What do you do about coverage?
I just removed Coveralls information. For Codecov the script that @dilumaluthge provided, as always, works flawlessly, I did not change anything related to coverage.
Ah! Notice that you need to add ssh: ${{ secrets.DOCUMENTER_KEY }} to TagBot.yml. Otherwise, the documentation of the tags will not be built automatically.
EDIT: TabBot.yml not TagBor.yml 
Great, I see what you mean. Thanks.
1 Like
Github actions are great! I see it as an improvement on the previous Travis CI & Co.
Does anyone have a cautionary tale? Should I try to keep Travis CI around just in case?
I moved from docs on github actions to the whole works in about a month. I’ve moved my travis.yml file to a place on my .gitignore list. I can see no downsides yet.
2 Likes
I don’t think there are any disadvantages - just seems like good practice to include the docs as part of the build test? I just removed the documentation section for some doc-less test packages.
Hi,
It worked for me!! Thank you a lot for the script 
However, despite the docs being. built (see here) they do not update. I mean the link do not show the updated docs. What did I forget?
Documenter keys probably need to be set. Deploy and secret.
2 Likes
exactly! Thank you
Help needed. I am lost with all these changes :-/
It would be super helpful if someone could make a tutorial/provide templates for how to set up all these tools for a typical Julia package (including package documentation).
After all, aside the package name, it should be the same for every package…
How to set up GtiHub Actions to publish documentation is already extensively documented in Documenter.jl manual. If you’re looking for templates, PkgTemplates.jl already provides them
3 Likes
Thank you. Concerning the automatic testing and line coverage the script to use is instead the one on top of this thread ?
Yes. Note that that script will also build the documentation, but to correctly publish it you need additional steps, which are in the link to the Documenter.jl manual above
3 Likes
@dilumaluthge: could you add a comment to your script that the branch on pull should be “main” instead of “master” for the new github repositories ?
3 Likes
@dilumaluthge Why did you add a separate run for the doctests here? Why not rely on the settings in the make.jl file?
I spent some time to get a Python/Julia/PyCall workflow going and would also like to share it here. It uses the System Python instead of the PyCall Conda version to build and look for installed Python packages. If you see room for improvement, that would be nice to know. Currently this doesn’t work on x86 systems.
name: CI
on:
- push
- pull_request
jobs:
test:
name: Julia ${{ matrix.version }} - Python ${{ matrix.python }}
${{ matrix.os }} ${{ matrix.architecture }} - ${{ matrix.os }} - ${{ matrix.arch }} - ${{ github.event_name }}
runs-on: ${{ matrix.os }}
strategy:
fail-fast: false
matrix:
version:
- '1.5'
- 'nightly'
python: [3.7]
os:
- ubuntu-latest
- macOS-latest
arch:
- x64
steps:
- uses: actions/checkout@v2
- name: Set up 🐍 ${{ matrix.python }}
uses: actions/setup-python@v2
with:
python-version: ${{ matrix.python }}
- name: Display Python version
run: python -c "import sys; print(sys.version)"
- name: Install dependencies 🔧
run: |
python -m pip install --upgrade pip
pip install -r requirements.txt
# Julia Tasks
- uses: julia-actions/setup-julia@v1
with:
version: ${{ matrix.version }}
arch: ${{ matrix.arch }}
- uses: actions/cache@v2
env:
cache-name: cache-artifacts
with:
path: ~/.julia/artifacts
key: ${{ runner.os }}-test-${{ env.cache-name }}-${{ hashFiles('**/Project.toml') }}
restore-keys: |
${{ runner.os }}-test-${{ env.cache-name }}-
${{ runner.os }}-test-
${{ runner.os }}-
- uses: julia-actions/julia-buildpkg@v1
env:
PYTHON : python # this sets the Python binary directly to build PyCall
- uses: julia-actions/julia-runtest@v1
- uses: julia-actions/julia-processcoverage@v1
- uses: codecov/codecov-action@v1
with:
file: lcov.info
docs:
name: Documentation
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Set up 🐍
uses: actions/setup-python@v2
with:
python-version: 3.7
- name: Set ENV Variables for 🐍 📞
run: |
echo ENV["PYTHON"] = python >> $GITHUB_ENV
- name: Install dependencies 🔧
run: |
python -m pip install --upgrade pip
pip install -r requirements.txt
- uses: julia-actions/setup-julia@v1
env:
PYTHON : python
with:
version: '1'
- run: |
julia --project=docs -e '
using Pkg
Pkg.develop(PackageSpec(path=pwd()))
Pkg.instantiate()'
- run: |
julia --project=docs -e '
using Documenter: doctest
using GraknClient
doctest(GraknClient)'
- run: julia --project=docs docs/make.jl
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
3 Likes
Thanks @dilumaluthge for preparing this! Makes it really easy to switch.
May be you can add to the recipe the need to add and the DOCUMENTER_KEY to github.
Another bump for me was the compat section in docs/Project.toml which pinned Documenter to an older version. Only recent versions seem to know how to deploy under github actions.
One question though: travis had builds for MacOS and windows. Is it possible to have them here as well ?
strategy:
# ...
matrix:
os:
- ubuntu-latest
- macos-latest
- windows-latest
2 Likes
Great, thanks - it works. I’ve seen the docs, but I was not sure where to put this stuff into the ci.yml…
I also suggest then to name the ci action to reflect that it runs on theses systems:
Instead of
name: CI
write (e.g.)
name: linux-macos-windows
Then one can use as the badge in README.md:
[](https://github.com/me/MyPackage.jl/actions)
1 Like