Publishing salt-server-list.rst back to psf-salt onchanges

[cegerhardson]

Publishing salt-server-list.rst back to psf-salt onchanges

[ewdurbin]

I think a variant of this idea might be best:

Another avenue may to be establish a githib workflow that runs on a scheduled cron interval, pulls changes from salt using salt-cp, and creates a pull request using create-pull-request action.

I don't think we can use salt-cp since GitHub Actions runners aren't part of.... and I don't think we want to add them to... our salt installation.

Rather, we could potentially publish files over HTTP from the salt-master that we want to fetch. Similar to the way that we have the salt-master respond to LetsEncrypt acme-challenges in

psf-salt/salt/base/salt.sls

Lines 60 to 81 in 24fae9b

	/etc/nginx/sites.d/letsencrypt-well-known.conf:
	file.managed:
	- source: salt://base/config/letsencrypt-well-known-nginx.conf
	- user: root
	- group: root
	- mode: "0644"
	- require:
	- file: /etc/nginx/sites.d/
	- sls: tls.lego
	/etc/consul.d/service-letsencrypt-well-known.json:
	file.managed:
	- source: salt://consul/etc/service.jinja
	- template: jinja
	- context:
	name: letsencrypt-well-known
	port: 9000
	- user: root
	- group: root
	- mode: "0644"
	- require:
	- pkg: consul-pkgs

, we could:

• Create a new /srv/public directory
• Change the psf_known_hosts and salt-server-list.rst managed files to be created in that directory
• Add an nginx config and consul-service that serves that directory over HTTP
• Add a service to our loadbalancer that exposes that HTTP service to the world
• Outside of salt, we would add a DNS record pointing to that domain on the loadbalancer

Then our scheduled GitHub Action can access the files via HTTP, see if they've changed, and use the create-pull-request action to open a PR when they do.

[ewdurbin]

This is complete. #343