Closed pivotalgeorge closed 4 months ago
an alternative implementation would be to use repository_dispatch [see here for changes on the target-workflow side.] Both link to this detail in the REST doc.
I was about to open an analogous PR - something like #trigger-docs against CCNG since we reversed the desired trigger direction (building GH Pages docs under capi-release with the contents pulled from CCNG)
However, upon reflection it seems like this should already be handled by docs changes making it into capi-release
as submodule updates and triggering a docs build on every Release
+ @moleske @sethboyles @evanfarrar since y'all were part of the CCNG <-> CAPI Release conversation as far as triggering on version changes goes => Let me know if your understanding is different -- otherwise I will close this PR
I have no strong feelings one way or the other.
I was mostly curious what the plan/goal was. If we don't think we need to trigger on versions cause every docs commit causes a deploy to happen that's good enough for me. I think the repository dispatch implementation would be unnecessarily complicated for what we want
edit - actually what I want is to delete the v2 api, but today will not be that day (joking but not really)
Thanks for contributing to the
capi_release
. To speed up the process of reviewing your pull request please provide us with:A short explanation of the proposed change: An Actions Workflow to trigger rebuilding docs
An explanation of the use cases your change solves This addresses the concern in discussion on https://github.com/cloudfoundry/cloud_controller_ng/pull/3874 about the v2 GitHub Actions workflow not being directly triggered by new CAPI tags/releases
Links to any other associated PRs see CCNG#3874 above
[x] I have viewed signed and have submitted the Contributor License Agreement
[x] I have made this pull request to the
develop
branch[ ] I have run CF Acceptance Tests on bosh lite N/A - no code changes to the release / anything that would be covered by CATS - this is a new Workflow file