Figure out how we're going to automate building of ansible (if we are)

[abadger]

ansible-base is built in a private jenkins instance.

ansible should be built in a way that community contributors can take over in the long run. This means the jenkins instance is probably not going to work well.

I thought a github action might be the best way to build. But there's no obvious repository/tag to do that:

• ansible-build-data holds artifacts from the build. So we really should tag that repo after the build is done.
• antsibull doesn't have source code for the ansible. It's just a tool for building ansible.

Maybe a two step action in ansible-build-data?

• Someone adds a tag like "build-ansible-2.10.0alpha1".

• That triggers a github action which pip installs antsibull and then runs the build steps

• And then runs the pypi upload steps

• And then tags the ansible-build-data repo

• How do the debs get built and uploaded to launchpad?

• On launchpad, we share a PPA account with ansible-base because launchpad has never told us how to get an ansible group... we have just an ansible user.

• Looks like no one has written a github action to deploy to launchpad yet. So we'd need to write that from scratch.

[abadger]

Possibility: request to use a free jenkins instance:

• CPE, https://docs.fedoraproject.org/en-US/cpe/ manages a Jenkins instance for centos and fedora. We could request access and if granted could do our build and upload to pypi and launchpad ppa from there
  • do they have access to ubuntu workers or can we use an Ubuntu container there?
  • We'd still be splitting the launchpad ansible account between the private Jenkins instance and another place

[abadger]

Outline of how doing this via github actions might work:

• Use a repository_dispatch trigger to start a build:
  • What is repository_dispatch: https://help.github.com/en/actions/reference/events-that-trigger-workflows#external-events-repository_dispatch
  • this is how you trigger it https://developer.github.com/v3/repos/#create-a-repository-dispatch-event
  • payload explained: https://developer.github.com/webhooks/event-payloads/#repository_dispatch
• That invokes a workflow which installs and runs antsibull-build to create the ansible tarball.
  • Create a PR against ansible-build-data to add the new deps file.
• Run the ppa/pypi-publish Action to upload to pypi
  • https://github.com/pypa/gh-action-pypi-publish ?
  • Example of using it: have a state-of-the-art GHA workflow example in pylibssh
  • Tutorial: https://packaging.python.org/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/
• Build the deb and upload to launchpad:
  • Ubuntu is the default linux VM that you get in GHA
  • Example of how deadsnakes does it: https://github.com/deadsnakes/python3.10-nightly/blob/master/.github/workflows/main.yml

Advantage of this over CPE jenkins is that we don't have to depend on another external service. It
depends on other things that GitHub maintains.

This does have the same question of splitting credentials for the ansible launchpad account over
both the private jenkins instance and github secrets.

[abadger]

@webknjaz CC'ing you on this one since you're looking into producing ansible nightlies via github actions. I think if that happens, it makes a lot of sense to put the other parts of the build in github actions as well.