Add kitconcept.seo. Fix #27

[tisto]

No description provided.

[tisto]

@ericof @davisagli CI fails on this and I honestly have no clue how to fix this:

make lint-isort
...
============================
Starting plone-code-analysis
============================

Running check: isort
====================
ERROR: ./src/plonede/setup.py Imports are incorrectly sorted and/or formatted.

=======
Results
=======

There is no "make fix-isort" or any information on how I could fix this.

[davisagli]

@tisto make format runs all the automatic formatters

[tisto]

@ericof @davisagli @fredvd now the deployment fails:

https://github.com/plone/plone.de/actions/runs/7172836707/job/19531088698

It seems my credentials for testing.plone.de are also not valid any longer.

[fredvd]

@tisto I think this is a devops configuration issue (I caused) and a misleading error. Where the workflow fails is in fetching the created image to the docker swarm worker node. And it says it tries to login as user Tisto, but we have created long lived access tokens for this.

Last year we configured that secret (DEPLOY_GHCR_READ_TOKEN) on the repository level, when I expired this november I created a new one on the Plone organisation level on Github. And I thought I had all repositories selected that can 'inherit' that token, but I forgot plone.de (and the expired secret should be removed from the repository settings because otherwise it stops acquisition to the top org level :-P) I just fixed that and restarted the testing frontend deploy.

The frontend testing action now succeeded: https://github.com/plone/plone.de/actions/runs/7181585182

---

Too much devops info: that you now see that user tisto in the action run could be because by default every github action run gets an ephemeral short lived access token that is generated from the user that starts/configured the action. With that token you can also download packages from ghcr to a docker swarm cluster..... but the token is invalidated after the action has run.

The problem with docker swarm: we do a release, say plone.de:1.0.20 is downloaded to worker1, Docker swarm in its central state store saves this access token. 3 weeks later the container needs to move to worker2 for maintenance, docker swarm instructs worker2 to download the image from ghcr.io to worker2.... and the token is long invalid.

That's why we generated a long lived PAT (with read only permisions for ghcr, nothing else), put this in the secrets and pass this token in docker-stack-deploy to the swarm manager, so it can redownload the image later.

(I only learned halfway this year that you can update the credentials in the docker swarm distributed store by logging in to a manager and doing a "docker service update" for that service with some extra parameters where your docker client passes/refreshes registry local credentials to the service/stack object in the swarm.

You 'should' be able to download public images without any authentication, but we have had multiple issues this year also on local developer desktops that expired credentials are passed they, stop /abort a workflow or download, even if the image is public and the credentials should't be needed.