Closed thatbudakguy closed 2 years ago
✔️ Deploy Preview for sul-wallscreens ready!
🔨 Explore the source changes: 50000dce4b650330a314952711ed395f76eb7385
🔍 Inspect the deploy log: https://app.netlify.com/sites/sul-wallscreens/deploys/619c1ceeeb50b80007c40033
😎 Browse the preview: https://deploy-preview-241--sul-wallscreens.netlify.app
closing pending later discussion on how to deposit wallscreen artifacts; see #196
closes #213 branched from #235
this is a proof-of-concept demonstrating how we could create separate builds for each wallscreen. it relies on two important underlying changes to work:
if you check out the branch you'll get a lot of build warnings about files not being available — you can follow the warnings to move the contents of the
local-media/
folder into each of the experience folders. each experience has its ownlocal-media
,thumbnails
,attract-images
, etc. alllocal-media
folders are already gitignored. of course, you can also ignore the warnings and just test it using fallback images.to test the build, you can invoke a build that includes a special config file, the example of which is
_wallscreens/silicon-valley/_config.yml
. this file will exclude other wallscreens from the build, and set the homepage to point at the wallscreen that's being built. to do so:note that jekyll takes both config files in the order specified and merges them, so the latter one overwrites the settings of the former. the lack of spacing around the comma is important so that the shell doesn't misinterpret the command.
builds produced in this way will include only the media specific to the wallscreen being built, and upon starting a server (just substitute
serve
forbuild
in the above command) will navigate to the "index" page for that wallscreen (see #235).to create a build archive, you could use the above build command but append
--destination [dir]
which will output the build to the folder of your choice. you can then compress and upload it as an archive.you could also use this approach as-is to generate one build per wallscreen; the result should be able to be deployed and work normally. you could add wallscreen-specific metadata to the per-wallscreen
_config.yml
files to make it available at build-time (for example, a unique analytics ID or environment value).