20:00:14 #startmeeting Ansible Windows Working Group 20:00:14 Meeting started Tue Jan 11 20:00:14 2022 UTC. 20:00:14 This meeting is logged and archived in a public location. 20:00:14 The chair is jborean93. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 20:00:14 Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:00:14 The meeting name has been set to 'ansible_windows_working_group' 20:00:27 sleepin' on the job ;) 20:00:27 * jborean93 letting the team down with that abysmal lateness 20:00:44 #chair nitzmahone 20:00:44 Current chairs: jborean93 nitzmahone 20:00:51 * nitzmahone lurks 20:01:17 no topics https://github.com/ansible/community/issues/644 so straight to an open floor 20:01:21 #topic open floor 20:01:25 hello 20:01:32 Hey 20:01:50 👋 20:02:12 the docs build stuff I mentioned last week has its own repo now: https://github.com/ansible-community/github-docs-build 20:02:37 nice 20:03:08 and I'm looking at an example/proof of concept for publishing to GH pages, so that the full capabilities can be done all self-contained: https://github.com/ansible-community/github-docs-build/discussions/9 20:03:49 cool, so that would be used for the collection docs? 20:04:05 that might end up being a good for for the Windows collections too, and could remove the need for the RST files in docs completely; instead having a browsable, published site 20:04:41 yea I would be all for removing that step from the process 20:04:59 yeah it could be used by any collection to (for example) host their own rendered docs, both for `main`/stable branches, and for PRs (temporary builds showing the changes in a PR) 20:05:12 plus having it be built from source rather than committed each time will simplify a lot of things 20:05:37 it's what I already do for the hashi_vault collection, but I'm currently hosting on surge.sh; doing it all within github would be nice, no external services/secrets/tokens 20:05:41 Yeah, +1000 to the "no commits from build pipeline" thing :) 20:05:54 That's a big can of worms 20:06:22 wellllllll publishing to GH pages _is_ committing from the pipeline... but it'd be on a dedicated branch for the pages, not a branch including any actual collection content 20:06:54 usually it's a branch called `gh-pages` (but it's configurable) and it only contains stuff you want to serve over HTTP 20:07:02 Well, and can be to a different repo as well 20:07:25 yes it can! but that does introduce needing secrets of some kind (a PAT or a deploy key can be used) 20:08:00 That's still better than self-modifying the code SOT repo though IMO 20:08:11 I personally think the self-contained way is nicer, but I know how wary many are to committing in the same repo :) 20:08:28 I'm sure our prodsec team would veto self-modifying repos for anything that's Official Red Hat Supported 20:08:30 I'm personally fine with self-contained as a first step and potentially expanding as it goes along if needed 20:09:07 if it were a branch sharing any actual code I would agree with you nitzmahone , it being a separate essentially blank branch tips it for me back to single repo.. but I certainly see both angles to it 20:09:51 in any case, I'll have a sample/POC for people to look at, within the next few weeks I imagine 20:10:01 noice 20:10:03 I still have documentation and such to write for the existing build and PR comment steps 20:12:39 so yeah that's all from me at the moment 20:16:26 cool 20:16:45 thanks for sharing it, definitely interested in it for community.windows and see how it goes before looking at ansible.windows 20:17:00 if there's nothing else lets get back onto our day 20:17:08 makes sense to me 20:17:09 sounds good 20:17:18 enjoy! 20:17:19 #endmeeting