-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initial (Github Actions) Workflows for Ansible Community Package release #265
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you so much for working on this! This should streamline the process a lot. I'll comment on the actual code for now. I'll respond to the overall proposal later.
I would also remove the 8.4.0 release files. This combined with the 18 commits that aren't split into logical changes makes this a bit difficult to review.
ansible_version: | ||
description: 'Release Version. Example : 11.1.0' | ||
required: true | ||
ansible_major_version: | ||
description: 'Exmaple 11' | ||
required: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Future enhancement: make the workflow determine ansible_version
from ansible_major_version
,
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe vice versa?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, that's what I meant in the first place.
Still working on this, more things left to be updated. |
It enables the user to decide which Ansible Version needs to be built.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(nitpick) Let's the unnecessary YAML quotes that are added added inconsistently in arbitrary places.
@anweshadas another review round complete. Part of the comments are style normalization — you can safely accept the suggested changes in a batch from the Files tab in this PR. |
We tried to apply most of the feedback. PTAL. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You have my blessing, I suppose..
Requesting a review from myself. I'll give this another look. |
Other than that, this looks good to me. Thanks @anweshadas for all your work on this and for responding to all the feedback! This is really great. |
Co-authored-by: Maxwell G <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's get this merged so we can do further improvements in follow-up PRs :)
CI failures are unrelated. |
Thanks @anweshadas @gotmax23 @webknjaz for your work on this! |
Introduction
The Release Manager(s) (RM) for Ansible Community Package, are always the Ansible Community Team members, who are Red Hatters. But with this endeavor we are trying to open up the release process to the community members. So an interested and designated group of people can be Release Ansible.
Who can be the release managers for Ansible Community Package?
Anyone from the Ansible Community can be the RM for Ansible Community Package. We will be forming a Release Manager Working Group from the community who will be not only doing the release but also taking the decisions and responsible for work in and around the release process (barring certain reasonable restrictions and limitations).
Automation of the current release process
We are trying to automate the current release process with Github Actions (GHA). We wrote the initial workflow(s). This workflow tries to follow the current release process as much as possible.
Step 1
Run the ansible-release workflow to create the release PR to the ansible-build-data repo.
Step 2
After the PR is merged by a maintainer, run upload-to-pypi to upload the distribution packages to PyPI.
Step 3
After uploading the source to PyPI run docsbuild-release workflow to create PR to ansible-documentation.
Plan for betterment this workflow
Here is the plan to improve the intial workflow
The process needs to be divided in two parts: Pre-Release and Release
Pre- Release includes:
Pre-requisite : A new ansible-core release will trigger the Pre-Release workflow
Release workflow includes:
Pre-requisite : The release workflow will run (manually) only after the merging of ansible-build-data PR.
The new upstream recommendations for building and publishing from github action to (Test)PyPI:
pypa/packaging.python.org#1261