generate_settings.py should not copy plugins

[sebbASF]

The script currently copies all the plugins to each website repo.

This will make it very hard to maintain the plugins.

[gstein]

Totally agree. I said exactly the same on Slack. We will not roll out GHA Pelican handling with copy-plugins, and will keep all plugins in a centrally-located single-source maintenance location.

[sebbASF]

One solution is https://github.com/apache/infrastructure-pelican/pull/92 plus associated change https://github.com/apache/infrastructure-actions/pull/3 to the action.

[dfoulks1]

the workflow no longer copies plugins but uses pelican --print-settings to fetch plugins to the configured plugin path based on the pelicanconf.py

[sebbASF]

However, there are currently copies of the plugins in two repos:

https://github.com/apache/infrastructure-actions/tree/main/pelican/plugins

as well as in

https://github.com/apache/infrastructure-pelican/tree/master/plugins

That is better than having copies in every site repo, but still not ideal

[dfoulks1]

We're not going to be relying on anything in the infrastructure-pelican repo, it is to be archived. Everything required to run the action needs to be available in infrastructure-actions. The canonical plugins will reside in infrastructure-actions.

[sebbASF]

What about the Pelican Docker build then? Can that be moved to infrastructure-actions?

[sebbASF]

Note that it looks like the plugins and build script cannot be directly accessed from the action; they will have to be copied from somewhere.

So why not leave them where they are and fetch them from there?

This will minimise disruption.

[gstein]

Because we are going to archive infrastructure-pelican, as stated elsewhere. Infra-supported GH Actions will live in infrastructure-actions, and all necessary content for those actions will be moved/copied there.

Not sure what disruption you think will happen, but ENOCARE. We will make it work, in order to deprecate -pelican.