In terms of the final upload, ideally we would not be doing this on the actual nodes performing the builds. Not only for the security of the credentials themselves (which should be in as few places as possible) but also to ease deployment of the build nodes. (For Android builds, we have the undesirable state of affairs whereby the various signing keys have to be made available to those builds, which I want to move away from. Flatpak is similar, and I want to change that as well)

I've now initiated the rebuild.

The Docker image builds are already CI jobs, however they're manually triggered as it's usually pretty uncommon to need rapid changes in them.

Thanks for that fix - the site now generates successfully and has been automatically deployed.
https://binary-factory.kde.org/job/Website_konsole-kde-org/7/console

Thanks

It would appear that the commit of this change disturbed somethng with FreeBSD builds - see https://build.kde.org/view/Failing/job/Frameworks/job/kio/job/kf5-qt5%20FreeBSDQt5.12/135/

With regards to Windows, please note that any unit test which depends on calls that involve D-Bus on the CI system will likely lead to that test hanging because dbus-daemon is not launched by the CI system.
Where possible D-Bus should be avoided on Windows.

The Binary Factory uses the tooling shipped as part of the KDE SDK (which always builds everything from scratch, and I don't know if part of that includes ECM, hence why the issue doesn't show up there).

Please note that there are very few people involved with Windows builds (despite the number of projects that make use of them in general) so people may not always have the ability to respond to every review request.
That is why the CI system monitors the state of code and can catch issues as they happen.

This change appears to be responsible for all Android builds being broken.
See https://build.kde.org/view/Failing/

This change has unfortunately made MSVC unhappy - https://build.kde.org/view/Failing/job/Frameworks/job/kfilemetadata/job/kf5-qt5%20WindowsMSVCQt5.11/lastFailedBuild/

That message was occurring because your Gemfile specified an exact version of Jekyll, which i've now fixed.
While this has allowed the generation to proceed further, unfortunately it still fails due to encoding issues.

Could you provide a screenshot showing the change please?

At the moment there isn't a public task or anything i'm afraid (the list of outstanding items is only contained in discussions between members of Sysadmin at the moment).

Please note that Sysadmin focus now is on the Gitlab migration rather than Phabricator. Setting up all those rules you've asked for is likely to take more than an hour...

This change unfortunately does not compile on any platform tracked by the CI system.
Please see https://build.kde.org/job/Frameworks/job/baloo/

This changes breaks the build on Windows/MSVC because 'valgrind.h' doesn't support MSVC.
Can you please correct this / disable this check on Windows?

The files have now been released to the mirrors as requested.

Thanks for the quick update. Unfortunately I don't have a way of easily testing proposed patches, but in theory that should solve it yes.

I'm afraid MSVC doesn't like this change - could someone please take a look?
https://build.kde.org/view/Failing/job/Applications/job/okular/job/kf5-qt5%20WindowsMSVCQt5.11/161/console

I've now closed the Forum to new entries - it was still open to posts being made by users.

Alas, something about the Konsole website config makes it unhappy still - https://binary-factory.kde.org/view/Websites/job/Website_konsole-kde-org/3/console

Sorry, i'm not a massive user of gems/etc - you'll need to provide more detailed instructions or a patch to https://invent.kde.org/sysadmin/ci-tooling/blob/master/system-images/static-websites/Dockerfile

Please see https://binary-factory.kde.org/view/Websites/job/Website_konsole-kde-org/

The first builds must be started manually. I'll do that shortly

Master is fine in this instance. If the system fails to build the site for whatever reason, the current version of the website will stay up.

Perfect. I'll land this shortly.

This will get you most of the way there towards enabling it on the CI system yes.

Sorry, you didn't have any access to websites/konsole-kde-org, i've now sorted that out.

Kurt, could you please create a branch in the Konsole website repository containing this work?
I'll then be able to arrange the switchover.

As mentioned in my earlier comment, it is waiting on your approval for content Kurt.

Aleix is correct, Flatpak commands are not possible within the CI environment (as Docker is heavily locked down, and the containerisation and other isolation measures that Flatpak tries to take are locked out as a consequence)
Not to mention that Flatpak is Linux only as well, while Appstream data isn't applicable to multiple platforms.