Action the build farm from github actions

[RaymondCM]

Maybe we need to remove the jenkins badge also

[pet1330]

Do you mean the release process? These can be triggered manually here: https://lcas.github.io/rosdistro/

Badge removed in #24

[RaymondCM]

Is there a way of triggering on a successful github action? I would assume so since the triggering page above must construct some kind of request?

[RaymondCM]

We can also then set it to 1. trigger a release on a new tag when tests pass and 2. build the pypi package with github secrets and push to pypi?

[pet1330]

Yeah, the request that is generated looks like this:

curl "https://lcas.lincoln.ac.uk/buildfarm/job/bloom_release/buildWithParameters" \
-H "Content-Type: application/x-www-form-urlencoded; charset=UTF-8" \
--data-raw "repository=REPONAME&token=lcas&bump=BUMP&rosdistro=DISTRO&INFO=triggered+by+release+wizard"

So from a technical standpoint, this shouldn't be too difficult. REPONAME will be topic_store, ROSDISTRO will likely be melodic for now (at least until we move to ROS2). One challenge will be working out the bump, as this will likely change from one release to another.

However, when I spoke with @marc-hanheide about automating the release process in November, he has reservations, but I can't remember what the issues were now (something to do with the way people release software differently between different projects?).

As for pypi release, that should be do-able, I've taken a quick stab at it on the pypi-update branch (but it'll need your pypi token to be set as PYPI_API_TOKEN) 😃

EDIT: Although I'm not sure how to test it without making a new release... Maybe this should be done in another repo first...

[marc-hanheide]

However, when I spoke with @marc-hanheide about automating the release process in November, he has reservations, but I can't remember what the issues were now (something to do with the way people release software differently between different projects?).

Marc always has reservations, because he's old and conservative :-P

My argument was that people might tag repositories for other reasons than releases (e.g. after a workshop in April ;-) ). So I wanted to keep it git tags separate from actually triggering a release. I mean, clicking https://lcas.github.io/rosdistro/ after you have made the catkin_prepare_release on the repo is all that is needed. Otherwise, you'd have to implement the sanity checks of catkin_prepare_release in your GH action and only ping the release process of indeed you have checked that this is a proper version release tag and that package numbers are all consistent etc...