Initial (GHA) Workflow for creating the Porting Guide #121
Conversation
github-actions
bot
added
the
needs_triage
|
Retriggering CI. @anweshadas, what's the current status of this? |
| - name: Create the PR body | ||
| working-directory: antsibull/build/ansible-build-data | ||
| run: | | ||
| gh pr create -B test -H "publish-${{ inputs.ansible_version }}" --title "${CI_COMMIT_MESSAGE}" --body "${CI_PR_BODY}" |
There was a problem hiding this comment.
Should the branch be called test? (I assume that capital B means branch.. It's a good tone to use long explicit argument names in scripts since it makes it possible to read them easily)
There was a problem hiding this comment.
Let's stick to the test branch name for now. I have edited -B to --base and -H to --head.
| ##### COMPONENT NAME | ||
| docs/docsite/rst/porting_guides/porting_guide_"${{ steps.compute-version.outputs.major-version }}".rst |
There was a problem hiding this comment.
Sorry but it doesn't look like Sviat's suggestion has been applied. Or am I crazy?
Co-authored-by: Don Naro <dnaro@redhat.com>
oraNod
removed
the
needs_triage
|
@anweshadas Hey, I just pushed a commit to your branch. I thought that might be easier than adding a load of review comments here. Anyway I hope the changes are OK. Feel free to take them or leave them. I did use yamllint to check the syntax and tried to make things a bit more descriptive in the workflow. For instance, I renamed the job from "build" to "porting-guide" and also changed the name of the workflow file. Hopefully I have the right flow here too. My understanding is that this workflow is intended to extract the porting guide from the package tarball and then add it to the I was also thinking we could break this into three separate jobs:
Not sure what folks might think about that so I didn't go that far in my changes. Happy to take a stab at it if that would be useful. Hope these changes help! Cheers. |
|
Also it seemed unnecessary to me to have a step that uses sed to extract the major version and thought it could just be passed as an input. Guess we could change it back. |
|
Thinking about it some more and I think we could break the proposed jobs two and three into a reusable workflow. That should reduce duplication. The main difference between the two jobs is the path where the RST file goes. We could pass that as an input to the reusable workflow. Having the separate jobs should also mean that they run in parallel. |
|
Just pushed another commit with the reusable workflow. I think it's a bit nicer because the jobs run more independently. Here's what it looks like in the sidebar view:
I found that using an action for the PR means we can reduce some of the steps: https://github.com/marketplace/actions/create-pull-request However it ran into a permissions issue (always). I guess we'll need to work through that. It should be fine for this repo (ansible-documentation) because the settings allow for actions to create PRs. For the build-data repo I suppose we'll need a token or something. Another nice thing about using the PR action means we'll be able to specify things like labels, assignees, and reviewers. |
|
Another commit to add back the plain git steps instead of using that PR action. I guess we can decide which method to use. Just thought maybe I shouldn't change things too much. @anweshadas feel free to either squash that last commit or drop it. |
There was a problem hiding this comment.
The changes look good to me. Thank you @oraNod for working on it.
|
@felixfontein can you please have a look at it? |
Depends on ansible-community/ansible-build-data#265