Perl-Advent
Perl-Advent copied to clipboard
perladvent
script/build-site.sh fails
When running script/build-site.sh it always fails at the point where it tries to run advcal with the --https option, as that option is unknown to advcal.
Simply removing the --https option allows the script to run but since it isn't clear to me why this was ever included there may be more needs to be done to have it fully work as intended.
Are you using our fork of the advent calendar? https://github.com/perladvent/WWW-AdventCalendar It's included as a submodule of this dist. That may have been added to avoid warnings about mixed content. I'm a bit hazy on that part.
@thibaultduponchelle it looks like the submodule is a few commits behind. I see that you did add some logic to deal with incoming articles. It looks like I added some overlapping logic in script/render-incoming.pl yesterday. Not sure how best to reconcile those two. My aim was to get a quick way to view articles that had not yet been assigned a date.
Ah, no I was not. Will have to see about installing that and giving it a try but I expect you are right. Thanks.
@openstrike please feel free to self-assign anything you'd like to review. I didn't want to overwhelm you as I don't know what your time constraints are, but it looks like we're about to hit peak incoming article season. 📈
I guess I'll start assigning some dates to articles as Dec 1st in the UK is not far off. 😅
@openstrike see also .github/workflows/build.yml for a summary of how the site is being built. Ideally we'd have all that in one build script so that we could also run it locally, but that's what we have right now.
Currently installing Dist::Zilla and a mountain of plugins just so I can build and install the WWW::AdventCalendar fork. Perhaps a (private) release of that would be good so folks who just want to run the deployment locally don't have to go through this? I'll maybe make a tarball available.
It would be better yet to merge the changes upstream so the fork is no longer needed. But maybe it has diverged too much.
I don't think we've actually checked in with @rjbs about the changes in the fork. Mostly I think it has been convenient to use the fork as we don't require a CPAN release to be able to use the changes right away. We're usually in a hurry.
You could upload a -TRIAL release to CPAN and that would not step on anyone's toes.
We could also build a Docker image to make it simpler for everyone except the ones who don't want to download images. 🐳
Also, something like this could be used to build the dist: https://jonasbn.github.io/ebirah/
I get the being-in-a-hurry point. :)
However, come each January once the dust has settled would that be a good time to work at relative leisure to merge the changes upstream?
However, come each January once the dust has settled would that be a good time to work at relative leisure to merge the changes upstream?
I think if someone wanted to take that on, that would be great. It looks like we also maintain our own forks of Pod-Elemental-Transformer-SynHi and PPI-HTML.
I did push upstream the HTTPS change at https://github.com/rjbs/WWW-AdventCalendar/pull/8 but mainly for notification and did not left time to Ricardo to review and merge but closed PR since then.
Similarly I did a PR upstream (but by mistake) for SynHi changes https://github.com/rjbs/Pod-Elemental-Transformer-SynHi/pull/1 but our changes here are not ready to handle more than us.
For PPI-HTML it's another story, I think we don't really have upstream where to push.
About incoming, I would go one step further and ask if this separate directory is really needed?
