20:00:02 #startmeeting Ansible Windows Working Group 20:00:02 Meeting started Tue May 24 20:00:02 2022 UTC. 20:00:02 This meeting is logged and archived in a public location. 20:00:02 The chair is nitzmahone. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 20:00:02 Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:00:02 The meeting name has been set to 'ansible_windows_working_group' 20:00:06 boo 20:00:09 #chair jborean93 20:00:09 Current chairs: jborean93 nitzmahone 20:00:15 that's unlike you nitz 20:00:25 I got squirelled 20:00:49 hey 20:00:59 #info agenda https://github.com/ansible/community/issues/644 20:01:15 Nothing new there, though I did get around to poking at the docs build stuff 20:01:35 oh nice, anything to share? 20:02:46 While I agree you've got it locked down as well as it can be, and it does look pretty safe in its current incarnation, I think the general consensus among us is that it still should probably not run on PRs, at least for Red Hat supported repos. I haven't invoked our prodsec folks, but I'm betting they'd agree. 20:03:42 ok, it sounds like abundance of caution more than anything specific? 20:03:57 There are just enough moving parts that a write token to the target repo just shouldn't ever exist in a workflow IMO- if it were publishing those to a separate repo, I'd be all for it 20:04:57 Yeah, pretty much- your implementation looks very solid and keeps the write token limited to a single job where no user content is run, so I'd have no objections if you want to do that on non-RedHat Supported collections 20:05:43 (eg any of the community.* collections, just not the ansible.* and other supported stuff) 20:06:01 ok, publishing to a separate repo is possible, to do that we'd only need someone to create the repo and enable GH pages, and we'd need a PAT that can write to that repo's contents, and then that PAT would be stored in a secret on the repo where the ansible content is 20:07:08 in that scenario, the calling workflow needs a write token (because that's actually what gives read access to secrets), but technically the called workflow could drop to read in that scenario because the secret value has to passed in explicitly (reusable workflows can't read the running repository's secrets even with a write token) 20:07:17 so there's some steps to it, but it would be doable 20:07:28 Yeah- I guess I'd leave that discussion up to the community folks to hash out, but I'd be supportive of that- at worst case, leaking the PAT allows defacement of the docs site, which it technically already does via PRs anyway (just not the main directory) 20:08:11 yeah exactly, the distinction makes sense. I appreciate the thorough look at it! 20:08:53 I can modify the PR to not do the PR build, and just do the push workflows (which would publish `main` & tag sites), if that's acceptable 20:09:08 that would at least let us get rid of the RST docs and the process of generating them manually 20:09:19 Works for me 20:10:01 cool, thanks again 20:10:13 I do wish they'd get that `force_orphan` support working with `keep_files` though- that would alleviate my other primary concern with the overall approach (repo bloat), though that can be manually mitigated already as needed 20:10:48 yeah agreed; it's planned, so just a matter of maintainer time, or a contributor doing it 20:11:11 separate repo also mitigates that, since we wouldn't care about bloating a docs-only repo probably 20:11:13 Seems like that could probably be manually simulated by doing `keep_files` false and manually reassembling the dir or something with `force_orphan` 20:11:22 yeah, true 20:12:09 I really wish GHP could use a separate internal repo or submodule or something... Actually wait- can it? 20:12:20 I never really thought through a submodule for that 20:13:23 right, I could make workflow steps that could save the docs content and restore it or something, at that point it's almost like, why use the action instead of just doing git commands. Anyway bloat will also be much less concern (for this repo) without the PR workflow which is where most of the churn would come from 20:13:53 yep 20:14:06 hmm I don't think a submodule is supported, it requires a branch 20:14:47 Oh I just meant as far as if the pages engine would fetch a referenced submodule in the gh-pages branch content 20:15:34 ahhh interesting.. I doubt it though. The jobs run in the background are now visible in the actions tab so you can at least see their output, ight provide a clue 20:15:40 can't see their source though 20:15:41 It doesn't directly solve the problem of needing to update stuff, other than it could potentially be done in a completely different repo and just update the submodule ref on a trigger while still allowing the docs pages to show up in the original repo 20:16:25 IIRC submodule refs have to be a SHA, not a branch/tag 20:16:33 Might be worth poking at though 20:17:00 a branch/tag would be perfect, but I don't know what you'd have to do to get it to re-fetch without a push 20:17:12 * nitzmahone makes note to play with that 20:17:42 Anyway, that's all I had on that for today 20:17:48 #topic open floor 20:18:03 I've got nothing thrilling to add 20:18:12 #agreed briantist to update c.w PR to only use `push` trigger on `main` 20:19:05 I'm wondering if it would be worth it though if there's another repo anyway, pages showing up in the actual repo isn't a huge concern from my POV anyway. The domain is based on the org (and in any case a custom domain could be used with pages), and the repo looks like a subdirectory 20:19:14 https://docs.github.com/en/pages/getting-started-with-github-pages/using-submodules-with-github-pages 20:19:18 Looks like you can... 20:19:33 oh neat 20:20:26 in some ways, a single central docs repo that all the included collections can use might be nice. More upfront setup but then maybe simpler per-repo setup... could be something worth looking into 20:21:00 I guess that is a big attack surface for any one repo being compromised , able to deface the docs for all the collections 20:21:26 though these are not supposed to be the official docs really.. but still something of a concern for blast radius 20:21:43 Yeah, could maybe also do that but use per-repo staging branches in the single shared repo, and submodules for docs in the leaf repos so the docs still appear in their respective places 20:22:33 ahhh true ture 20:23:13 (though doesn't solve the blast radius problem any better, other than still maybe not requiring pushes to the target repo) 20:23:47 I haven't used PATs much but I assume they cannot be scoped to a single branch 20:24:27 At a glance it looks like the submodule ref still has to always be a SHA (ie, not a branch/tag), even if you use .gitmodules or something, so while submodules would very much solve the bloat problem, it doesn't alleviate the need to make *some* kind of update to the original repo to see updated rendered docs contents :( 20:24:40 Nope, repo-only granularity IIRC 20:25:08 (well, you can do branch protection that would apply to PATs, but IIRC the PAT itself is always write-all) 20:25:33 * nitzmahone double-checks that 20:26:00 could have a job that updates the submodule SHA.. but seems like it's turning into a rube-goldberg machine with a lot more moving parts at that point 20:26:45 exactly- I had a similar thought, but I think the `pull_request_target` + having the `content: write` stuff in a dedicated job more or less achieves the same isolation with a lot less work :D 20:27:52 I was initially looking at attacking the runner agent until I realized you'd isolated that to a single job, so reusing an agent that was compromised by a previous read-only step shouldn't be possible 20:28:34 yup, that's what I was explaining previously, but I think sometimes you have to go through the motions make it click :) 20:29:16 Yeah, I had to really trace through the whole thing- I think the weakest link in the whole chain ATM is the github-docs-build repo since it's using a branch ref instead of a SHA 20:30:22 yes, it's really tricky, I have ideas on how to address that, they are unfortunately far from simple: https://github.com/ansible-community/github-docs-build/issues/4 20:30:56 Looked like pretty much everything else is locked to a specific SHA, and the NPM stuff for the GHA publish action is all locked to specific versions/hashes 20:31:58 s/GHA/GHP 20:32:02 right, I am trying to move in that direction for everything, in all the repos I work on; I usually give a pass to GitHub-owned actions (anything that starts with `actions/`) and use the major version tags, but for anything else, going SHA 20:32:38 Heh, yeah, if someone successfully attacks the GHA infra and core actions, we're all screwed 20:32:55 I still need to tinker with dependabot for helping make that process a bit easier in terms of keeping the SHAs up to date but for now I'm ok with manually doing it here and there 20:32:59 haha right 20:34:06 Welp, nothing else from me for today 20:34:49 same 20:36:24 OK, til next week then- thanks all! 20:36:30 thanks! 20:36:32 #endmeeting