Jenkins job and Github release - Help needed

[matentzn]

I would like to finalise this question now a bit: How can we trigger an ontology release from a Jenkins job.

Our setup now often looks something like this:

A) A Jenkinsfile contains the instructions to run an ODK release of an ontology and serves the files
B) Someone downloads the files supplied by the Jenkinsserver and creates a "current" and a "v2020-08-03" dated release (with all the downloaded files). This requires first deleting the current tag, then creating it again with the new release.
C) If the release files are small enough, the release is managed as part of github repo (usually default if the files are small enough to fit in the 100MB filesize limit)

If we could close this gap in a nice way, actually having the Jenkinsjob (or a separate one) doing the release, then we can automate the entire release process (like GO does), for every ontology in a generic way. Imagine this: releases would simply be created once per month (or once per quarter), without much human intervention.

Note:
We should probably not trigger a release if nothing has changed.

The biggest problem in my head, apart from the sociotechnical ones, is: how can we give the Jenkinsjob permissions to make releases in a more or less safe way? @balhoff has always suggested ontobot - is that safe? I think so, but maybe lets get some arguments, especially when it comes to automatically create releases.

Does anyone have any opinions on how to best do this? I would implement it, but I would really like to get some consensus on the strategy.

[balhoff]

The biggest problem in my head, apart from the sociotechnical ones, is: how can we give the Jenkinsjob permissions to make releases in a more or less safe way? @balhoff has always suggested ontobot - is that safe? I think so, but maybe lets get some arguments, especially when it comes to automatically create releases.

At the moment I only use ontobot to open pull requests, not to make releases. Since pull requests have to be merged by maintainers, I think it's perfectly safe in that regard.

[matentzn]

Yeah, probably best to have github releases as a manual step.. but maybe having it scripted is a good idea.

[jamesaoverton]

My $0.02 CAD: Have a release script and/or make release task that will create a draft release on GitHub, then a human reviews and completes the release. It will require an authorization token. This would be useful to run manually, and could be automated with Jenkins if desired. If automated, make sure to notify somebody who is authorized to complete the release.

I guess eventually the GitHub CLI will help with this, but it doesn't yet. Until then, I'd like to (re)use a script like this without ODK.

[matentzn]

I agree with you @jamesaoverton. This is how we will do it. I have the beginnings of a script, will share it once its done.

[matentzn]

For now, GitHub releases works well enough for us. no need to go back to this.