Externalise festival/year list

[leccelecce]

I'm conscious that currently adding a new festival or adding a year to an existing festival requires a code change, push to repo, pull from repo your end, recompile, restart and cache warm.

I plan to add quite a lot of European festivals to add. As a result I was thinking it would help to externalise the festival list from pages.ts, possibly just in a simple txt file so that it can be updated alongside the lineup file. The cache warming script could use the same source.

This would mean that a new festival or lineup could be updated with simple txt file changes, no rebuild required. Potentially these could also be supplied via a route other than the main repo in future. A local-only API endpoint could be added to trigger the reload of the festivals text file. That would potentially open the door to automating some more of the process in future.

If you agree with the direction of travel I can start on a PR.

[second-string]

I had planned on consolidating the two lists of festivals for a while now. Like you say, there's no point to have a list in the cache script and a list in the main pages.ts file. The easiest move would be to move the one from pages.ts into constants (since the one in the cache script is a subset of info contained in the main list) and have both places use the list from there.

I see what you're saying about having just text metadata for each festival that doesn't require a rebuild, but I don't think it's necessary to add a third file into the mix. I think to go that far, where festivals can be added without recompiling, the festival metadata would just be included in a header in head lineup file. Probably easier to convert the whole lineup file to a better format, like yaml, going forward. That way, when a cache warm v2 is run, it parses and saves stuff like the display name, region, etc, in redis along with all the other artist and song info. That way the site just always fetches what's from redis and the script and shove new festivals in in the background, and to add a new lineup a new lineup file is created and then cache warm v2 script run.

So a lineup text file could look like (exact format tbd obviously):

display_name: Nos Alive
slug: nosealive
year: 2022
days: 0
artists:
  - blah
  - blah
  - blah

And then if you really wanted the ability to add externally it would be a form on the site that would take all fields in and then just generate a file and run the cache script.

That being said - this is a very non-trivial amount of work, and I'm not sure it's really that necessary to change the current system to support it. While the current 'text file for every lineup' system isn't the greatest, it requires a trivial amount of effort to add new lineups. I'm currently of the opinion that the time spent to set up a simple CI/CD pipeline to rebuild, run the cache script, then restart the server to pickup changes, would be better served than overhauling the entire festival entry system. Happy to hear your argument though!

[leccelecce]

So the pull request referenced covers off your first paragraph and is a small step on the way.

Thanks for the feedback on the idea more generally- I will respond properly to this shortly when I get the time to finish thinking it through

[leccelecce]

Some work towards this is now in #46, in that festival-level data can be included in a lineup file. However, it's not currently used to dynamically add/update a festival (though the slug name and year are checked for consistency)