search

scholarslab / scholarslab.github.io

World Wide Web site! For the Scholars' Lab!
https://scholarslab.lib.virginia.edu
12 stars 6 forks source link

Test GH-based deployment workflow #992

Closed amandavisconti closed 2 months ago

amandavisconti commented 3 months ago

~Plan~ (instead, see messages below for latest version of to do list): ~1. Test out GH Pages + Actions for site build/deployment (to replace current UVA server and deployment code) *~ ~2. Test if redirects (may need Jekyll redirect plugin) satisfy our redirect needs AND work with GH Pages plugin limits, GH actions~ ~3. If simple, test if GH Actions can implement site search (and update/create ticket re:search either way, so Jeremy knows re:design and open fall work)~ ~4. Talk to Shane~ ~5. Temporarily remove search from site, if GH Actions don't have easy solve now (to explore/readd in fall after other retheming work done)~ ~6. Point domain at GH Pages-hosted site~ ~7. Make repo private (unless decide otherwise; Jeremy is interested in open, and Shane may be; both did not respond until a while after the deadline request, so fine with proceeding as planned for now but at least consider in fall once have time to adjust licensing, credit info)~ ~8. Explore regaining Netlify-like build preview via free action: https://github.com/rossjrw/pr-preview-action Amanda started testing out actions deployment on new repo 7/2 (https://github.com/scholarslab/deploydog); see also my research here below~

Background work (completed!):

Pros:

Cons:

Options for SLab website hosting and deployment:

  1. stay as current (UVA server; deployment code that has needed frequent sleuthing)
  2. move to all on GH (using GH Pages and Actions; i.e. all hosting, deployment)
  3. use some of each (e.g. GH build preview action but host on UVA server)

My (Amanda) preference is currently #2 (all GH); reasons below. Talking with Shane 7/10/2024 about his preference for (#1 or #3?).

My (AWV) reasons for moving to all-GH:

  1. Not dependent on Shane: e.g. when on vacation in Italy, winning lottery. Point of WP=>Jekyll move was largely reducing bottlenecks only 1-2 staff can address, distributing and reducing dev labor. (We’ve had at least 5 instances of the site not updating this summer because of the GH=>UVA server code deployment.) Very grateful for Shane’s work on this! And don’t want him to continue to need to manage and interrupt his other work for this (as a business decision, as well as seeming fairer).
  2. Something I can troubleshoot myself, troubleshootable and visible by all staff (starting with all dev folks; empowerment, learning, avoiding more bottlenecks). Doesn’t require SSH/command line/understanding undocumented code and server settings.
  3. Much better documentation, clear customer support from GH when/if we do run into issues.
  4. Knowledge transparency/learnability: others can look at our repo and fully understand/mimic how we run our site (similar reason to why we want to keep our repo public not private). E.g. users of peer-reviewed piece on our collab web stack by Brandon/me/SLab community in Programming Historian ran into a hidden piece because of UVA server and webhook (at that time) use.
  5. More control vs. unknowns of UVA IT and UVA Communications, Library policies (server control, unknown schedule of migrations, having changes made without asking us first).

This is a change I can implement myself, and prefer to perform myself (since I document things quickly for others to also learn; and to confirm my understanding of all pieces involved).

Research on impacts of moving to all-GH:

  1. Redirects (making sure visiting old links brings people to current pages): still need to doublecheck this is easy to transfer our existing redirects to, but I use the Jekyll redirect plugin (which is allowed by GH Pages) for other sites fine
  2. Build (creating the final HTML pages web visitors will see): just works (current regularly doesn’t), without requiring local build (good for staff accessibility); gives visual report on build/deploy status; public, well-documented error messages when error happens (vs. current custom code)
  3. Build preview (preview what site will look like when your changes are published, before actually making them public): currently researching (multiple action candidates exist); or can consider paid tool, given benefit to authors
  4. Search: Researching options, but I do not feel it is disqualifying if we need to remove search temporarily or permanently (most dev staff didn’t know we had search). Options include monthly local rebuild/push of Lunr.js search; embed Google search; explore other GH actions. Going to test this JS option that purports to be lighter than Lunr.js and faster than Google embed. Only searches on title, url, category, tags, date, post description (if we include any) is probably why—looks like we could add any YAML. So depends on how important full-text search is to us.
  5. Billing/data limits: I researched and do not see any issue here. GH rate limits/costs:
    1. GitHub Pages sites have a soft bandwidth limit of 100 GB per month. (Not an issue for us.)
    2. GitHub Pages sites have a soft limit of 10 builds per hour. This limit does not apply if you build and publish your site with a custom GitHub Actions workflow. (Not an issue for us.)
    3. GitHub Actions usage is free for standard GitHub-hosted runners in public repositories, and for self-hosted runners. (i.e. we are not cost-limited on Actions)
    4. Our current grand-parented GH plan costs us $0, with no indications that will ever change. Should it change and should that make this too costly (unclear it would be too costly, even if it did cost us more than $0), we can always return to our previous UVA server setup.
amandavisconti commented 2 months ago

Build preview research:

amandavisconti commented 2 months ago

Tested if GH Pages updates site build successfully, without Action setup, for

  1. Change to text (via browser index, no local build) = YES
  2. Change to theme = YES (assets/css/style.scss) = YES
  3. Change to data (post YAML's title; post content) = YES

Also looked in docs and verify GH Pages does this automatically for Jekyll. I.e. GH Pages handles building the site for us automatically without further work/Actions setup needed.

amandavisconti commented 2 months ago

Moved work that needs to be held until after all site renewal priorities completed and published to web (search #1009; build preview action #1010).

(No longer making repo private at any point.)

amandavisconti commented 2 months ago

7/13/2024 verified redirect plugin works!

Redirects I created

~Struckthrough~ items below as I add the redirects on my local instance of the realignment branch; all now done, or moved into "not setting up redirects for these" section. Note that some pages ultimately use YAML permalinks instead of redirects (matching URL from current site, so no redirect needed).

Redirects I did not create

The following are redirects on the current server I decided not to set up for the new site, as I believe they should no longer be needed, and if used are better served with a 404 than continuing to include them as redirects. Long defunct location pages: RedirectMatch permanent ^/locations/alderman-library-rm-317/ /hours-and-spaces/ RedirectMatch permanent ^/locations/alderman-library-room-421/ /hours-and-spaces/ RedirectMatch permanent ^/locations/alderman-library-room-421-2/ /hours-and-spaces/ RedirectMatch permanent ^/locations/alderman-library-room-423/ /hours-and-spaces/ RedirectMatch permanent ^/locations/alderman-library-room-423-2/ /hours-and-spaces/ RedirectMatch permanent ^/locations/alderman-library-room-423-3/ /hours-and-spaces/ RedirectMatch permanent ^/locations/auditorium-harrison-institutesmall-special-collections-library/ /hours-and-spaces/ RedirectMatch permanent ^/locations/brooks-hall-common-room/ /hours-and-spaces/ RedirectMatch permanent ^/locations/brooks-hall-commons/ /hours-and-spaces/ RedirectMatch permanent ^/locations/brown-library-rm-133-clark-hall/ /hours-and-spaces/ Other pages that didn't feel like they should/could have redirects: RedirectMatch permanent ^/about/colophon/ /about/#how-was-this-website-made RedirectMatch permanent ^/about/accessibility/ /accessibility/ Pages below are from old WP blog URL formatting. Unclear how to mimic with Jekyll redirect plugin RedirectMatch permanent ^/announcements/(.)$ /blog/$1 RedirectMatch permanent ^/job-announcements/(.)$ /blog/$1 RedirectMatch permanent ^/digital-humanities/(.)$ /blog/$1 RedirectMatch permanent ^/experimental-humanities/(.)$ /blog/$1 RedirectMatch permanent ^/geospatial-and-temporal/(.)$ /blog/$1 RedirectMatch permanent ^/grad-student-research/(.)$ /blog/$1 RedirectMatch permanent ^/podcasts/(.)$ /blog/$1 RedirectMatch permanent ^/technical-training/(.)$ /blog/$1 RedirectMatch permanent ^/uncategorized/(.)$ /blog/$1 RedirectMatch permanent ^/visualization-and-data-mining/(.)$ /blog/$1

For that last set of potential redirects (from old WP blog categories), we might be able to use the Jekyll redirect plugin, but I think this is not something we should spend time on until the renewed site is pushed to the web. My guess is that we'd use the plugin readme's "customizing the redirect template" section to create a layout that would use liquid templating to move through all the blog slugs from the WP-era publication date ranges. (This would redirect a bunch of URLs no one will ever enter as they did not exist, e.g. /podcasts + all the blog titles from that era since we don't know which were in that category.) Or actually, we do still have WP categories in most posts as YAML categories, don't we? So maybe this is easier. Still not doing it for now, and asking others to not either until site renewal priorities done and published.

amandavisconti commented 2 months ago

~To ask about:~

  1. How do we manage scholarslab.lib.virginia.edu vs. scholarslab.org redirects how—in domain settings, not site files? (www vs. non-www; GH can manage https cert)

Shane: "We run the scholarslab.org DNS but not any virginia.edu domain. For scholarslab.org, we have separate records for the base domain and for each subdomain (www works just like, say, takeback)". Jeremy: says to ask shane, but "I"m pretty sure we automatically redirect any scholarslab.org/* traffic to scholarslab.lib using CodeFlare's DNS stuff; Then the rewrites and redirects for scholarslab.lib take effect."

  1. Does ending slash vs. none on any URL need to be managed? "I don't think so? As long as the pages are accessible with and without the trailing slash (or the rewrites work to add/remove the slash for consistency)."
amandavisconti commented 2 months ago

Latest list of to-dos:

  1. ~Check redirect GH standard option, action, or plugin satisfies our needs, works with GH Pages and actions~ done
  2. ~Talk to Shane again (after 7/9) about whether we can/should host on UVA server but use GH Pages/Actions (7/10)~ done
  3. ~Temporarily remove search from site (issue exists to readd, but wait until all theming/deployment work done first)~ done
  4. ~Update spring group, Brandon, Shane on deployment decision and plans~ Done on Slack #slab-org pinned post; scheduled messages for Monday scrum
  5. Find out who/how domain switch happens, so can do this quickly if/when we are ready to switch
  6. Point domain at GH Pages-hosted site
  7. Turn on https cert in GH settings
amandavisconti commented 2 months ago

Completed research and decision, moved remaining tasks to new ticket; closing this as #1013 handles the latter actual move to all-GH

amandavisconti commented 1 month ago

Noting /realignment branch commit https://github.com/scholarslab/scholarslab.org/commit/06f98249cf42ab942fa0365b4516291a4fe08fae addresses items in this message https://github.com/scholarslab/scholarslab.org/issues/992#issuecomment-2218265235 under "redirects I did not create", making old posts point to where these posts currently reside instead of using old broken links