01:30:21 -xmr-pr- selsta opened pull request #1266: user-guides: update fingerprint 01:30:21 -xmr-pr- > https://repo.getmonero.org/monero-project/monero-site/-/merge_requests/1266 08:02:02 selsta: don't we have to move from gitlab -> github anyway? Dunno 08:02:54 netrik182: that's my fear too. I think that if we aim to have many questions, maby would be better to have a TOC and then all the questions already open (without needing to click on them) 08:15:36 .merge+ #1266 08:15:36 Added 12:00:56 * ErCiccione[m] uploaded an image: Screenshot_2020-04-02 FAQ .png (198KB) < https://matrix.org/_matrix/media/r0/download/matrix.org/esNkPwvSxWazBJPiyjdqoJsD > 12:01:02 I'm going for this structure instead ^ 12:01:44 consider the 2 blocks on the top will be smaller and not everything is styled yet 13:18:42 Looks good. Then it'll be possible to have placeholders pointed to the answers 13:19:03 And use them outside getmonero as well 16:20:29 Is the site down? 16:21:46 Looks down to me. 16:22:38 I pinged fluffy 16:23:29 Datacenter has power outage 16:23:49 oof 16:32:03 Nice 16:32:22 netrik182: They are not in the screenshot but i already created anchors for that very reason 16:32:46 So we can point people to a specific question 19:18:52 https://github.com/monero-project/monero-site/pull/892 19:23:33 This would handle what, site builds after pushing commits? 19:23:53 also when opening PRs 19:24:44 we could also deploy every PR/build to a testing area so that it easier to review things but I see problem with it getting abused 19:25:50 At least for me, getting build tests on pushes would be more useful, since I don't have a local site build setup 19:26:11 what do you consider a build test? 19:26:45 it tests if the website builds fine but you can’t open the website 19:26:52 Right, that's what I meant 19:27:28 But that's helpful for me, at least, for the few types of PRs that I make for things like updating the list of papers 19:27:35 right, this is possible but we have to make sure it doesn’t get abused 19:27:49 It'd be the same risks as the main project has, no? 19:28:01 what risks does the main project have? 19:28:21 I presume whatever limits GitHub places on CI actions 19:28:26 Isn't that what you meant? 19:28:39 Right now, every push I make for project branches have several CI actions for build and test 19:28:46 yes 19:28:59 I see risk in people linking to malware and then trying to link the website around 19:29:31 Is this a risk with just testing that the site builds? 19:29:54 no 19:30:00 Oh, you mean the risk only exists with some kind of test deployment 19:30:01 got it 19:30:04 yep 19:30:09 Yeah, that seems reasonable 19:30:30 and TBH for me at least, just knowing that I didn't screw up something obvious that breaks the build is good to know 19:30:39 it is better than nothing, yes 19:30:42 and it doesn't require that PRs have people test the build specifically 19:30:54 thereby removing some work 19:31:26 we could make a bot that deploys the site on a comment 19:31:30 so that people can check the changes first 19:32:24 just an idea 19:36:58 How would that work? Not sure I follow 19:39:12 a maintainer / trusted person writes !deploy and the bot would reply with a link were the website is deployed 19:39:33 so that it can get testsed 19:39:39 without having to build it manually 19:41:25 and then it dies on some timer? 19:41:33 but writing such a bot sounds like a lot of work with rather little benefit :) 19:41:42 yes the website would get deleted after 1 month or so 19:42:13 Isn't there some quote about how many programmers prefer writing tools than writing other projects? =p