Github actions, testing, CI/CD

[nathangibson]

@wsalesky Happy New Year!

My idea of fun lately has been learning Github actions :-)

I've pretty much gotten it to the place that we can do the following automatically for data and app repos: On a pull request to development or master,

1. Draft a new release with an incremented version number.
2. Build the XAR and attach it to the release.
3. Create the docker container and upload it to the Github packages repo (where I could pull it directly to the server)

I would find this kind of versioning and updating process helpful, especially as we iterate quickly in the project's last year. But it would mean I should implement branch protections and that we need to be disciplined about using well labeled pull requests.

I would love to incorporate some testing into this process and I've investigated some different avenues. Some of them are over my head with Java, and I would need to check around on the eXist list for examples and suggestions. So, bottom line, which of these do you think are useful to pursue? My basic goal would be to head off the kinds of issues that in the past have caused certain pages or the entire app to produce error pages due to malformed code, but it would also be good to work toward formal XML validity for the data. (Don't know whether HTML validity is a realistic goal for the app, given our use of Bootstrap?)

Categorizing these according to the eXist docs on testing (http://exist-db.org/exist/apps/doc/testing):

1. Validation testing: This is the most important, and exist has built-in tools for this, but I'm not yet sure how to implement them into a CI environment.
2. Unit testing: Not so relevant for the stuff I'm doing, but what about for you as you develop?
3. Integration testing: Would like to test for broken links and error status pages e.g. using the docker container. Anything else we should target?
4. Stress testing: I don't think we need this, right?

Interested in your thoughts!

[wsalesky]

@nathangibson Wow! Great work. I am really interested in the process you have set up and perhaps using it for the rest of the Srophe applications.

I also agree that we are in dire need of some testing framework. I think validation and unit testing are the low hanging fruit, and have been thinking about how to write unit tests for a while now. I will do some more reading on getting testing working with CI and get back to you.

[nathangibson]

@wsalesky Very cool! I wondered if you'd think it's overkill.

At the moment the workflow files are scattered in pieces across different repos, but I'm close to having something coherent we can try out for the package-release-docker bit.

As far as validation, I was thinking if I'm disciplined enough about schemas we could use the "implicit validation" in eXist if there's a way to report back which files were rejected...

[wsalesky]

@nathangibson Not over kill at all, just good practice. I wish I had planned better in the early stages, but here we are. Yes you can use implicit validation, but I will need to do some research on who to test it in CI, will do some reading on it and let you know.

[nathangibson]

@wsalesky OK thanks!

Also, suggestions on what to name the docker data image? Or best practices in general? Since it'll already be coming from the usaybia/usaybia-data repo, "usaybia-data" seems redundant. Or just "data" or "data-exist"?

[wsalesky]

@nathangibson Do you mean the data xar? I would personally still use usaybia-data as you do not know what other apps you may end up incorporating into eXist-db.

[nathangibson]

I'm keeping "usaybia-data" on the xar, but I'm wondering about the docker image that includes exist and the data but not the srophe app. (It's helpful to have an intermediate image with the data that the srophe docker image can be built on top of.)

As far as I can tell, docker always retains the repo source on the image e.g. when you pull $ docker pull docker.pkg.github.com/usaybia/srophe-docker/docker-test you'll always see the usaybia/srophe-docker part on there right? So that's why I'm wondering if I should use the full, redundant "usaybia-data" or something else

[wsalesky]

Ah I see. I think I would still use usaybia-data for clarity, but it may not matter so much.

[nathangibson]

Okay, whew, I think the release workflow is ready on the usaybia-data repo. Take a look at the workflows and config files here https://github.com/usaybia/usaybia-data/tree/master/.github

There are some peculiarities regarding how the branches work, so make sure to read the inline comments before trying out the code elsewhere.

I need to document this better, but for now: if you label the PR with a label starting with "changelog: ..." it will use that to decide what the version increment will be.

Take a look at the draft release here as an example: https://github.com/usaybia/usaybia-data/releases

And Github has now changed its container registry (in beta). Packages are here https://github.com/orgs/usaybia/packages but note that the usaybia-data package is private for the moment, until I'm confident about what it is I'm releasing. :-)

Github workflows are incredibly powerful, but wow, it takes a lot of troubleshooting to get it right!

[nathangibson]

@wsalesky OK I now have the build & release workflow working for usaybia/srophe-exist-app -- you can see the dev docker image at https://github.com/orgs/usaybia/packages/container/package/usaybia-srophe-exist-app (currently private, requires login but I'll eventually make it public) and the draft release at https://github.com/usaybia/srophe-eXist-app/releases.

The app dockerfile starts from the latest data docker image.

I've set it up so that the Dockerfile and conf.xml files are in those repositories, and the exist packages are pulled in remotely using ADD. That's convenient since it means the workflow doesn't have to go to a separate repo for build info. Do you see any reason we should keep using this srophe-docker repo for such things or is it ok if we keep docker build stuff in those other repos?

If the latter, I can close this issue and open issues for the finer details in their respective repos.