Use CI for automatic testing

[AmaiKinono]

In #24, I said:

I plan to use https://github.com/purcell/setup-emacs. With it we can test on multiple Emacs versions. An example (from here):

name: CI

on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        emacs_version:
          - 25.1
          - 25.3
          - 26.1
          - 26.3
          - snapshot
    steps:
    - uses: purcell/setup-emacs@master
      with:
        version: ${{ matrix.emacs_version }}
    - uses: actions/checkout@v1
    - name: Run tests
      run: 'emacs -Q --batch -L . -f batch-byte-compile *.el'

---

@masatake said:

I plan to use https://github.com/purcell/setup-emacs. With it we can test on multiple Emacs versions. An example (from here):

Nice.

You may need a way to build readtags at the CI environment. See https://github.com/universal-ctags/ctags/blob/master/.github/workflows/c-cpp.yml

[AmaiKinono]

You may need a way to build readtags at the CI environment.

That's something I didn't thought about... To me it looks good to just build it in the CI environment.

One thing I'm not that sure about is the version. I noticed ctags now has a automatic weekly tagging, but I think it's good to just test it on the latest commit (assuming readtags won't break itself). After a stable ctags release we may want to test it on the latest release.

Using Nix and Cachix like https://github.com/purcell/nix-emacs-ci is another idea, but I have no experience with them.

[masatake]

When cloning u-ctags repo, you can specify a tag to pine. See https://ctags.io/2020/10/07/news/ .

[masatake]

I agree with you. I think you should use the latest code. I'm thinking about running citre's test at u-ctags side, TOO. So we can detect an issue earlier.

[AmaiKinono]

I agree with you. I think you should use the latest code.

The problem here is we want to make Citre work for people installing u-ctags from the software repo of their system, but at the same time readtags may add/fix things that Citre uses (e.g. I don't know if everyone already has the -S option in their readtags installation), so Citre actually assumes the readtags is latest. The fact that u-ctags doesn't have a stable release makes this problem more complex.

For now let's test it on the latest code since no others are really using Citre.

I'm thinking about running citre's test at u-ctags side

I guess you want to make sure client tools works on the latest u-ctags? I'm not very sure on this idea, but it's good to try. And I'm think the core part (citre-readtags.el) could be considered quite stable now, so running tests dealing with core part should be no problem.

Edit: I think I understand this idea now. Yes it's a great idea, running all tests of Citre could help both u-ctags and Citre to find problems. I shouldn't be fear about the test fails.

[masatake]

I guess you want to make sure client tools works on the latest u-ctags?

Yes. citre is a very special client tool. The head maintainer of Universal-ctags wants to use it daily :-).

[AmaiKinono]

The head maintainer of Universal-ctags wants to use it daily :-).

Wow that's so good to hear ;)

Actually i want to come up with a framework for language-specific support in v0.1. To do this I need to implement support for at least one language, and I plan to do it for C, and you could benefit from that.