-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test GH-based deployment workflow #992
Comments
Build preview research:
|
Tested if GH Pages updates site build successfully, without Action setup, for
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. |
7/13/2024 verified redirect plugin works! Redirects I created
Redirects I did not createThe 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. 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. |
- note updated ruby; push back to 3.0.4p208 in gemfile.lock, '~>3.0.4' in gemfile if that breaks things for GH Pages - moves parents fund page to a /work project - adds redirects plugin - adds redirects to all pages/subpages, including ones not in nav; see this GH issue link for a full list of the redirects covered (struckthrough ones are done, non-struckthrough ones are not done yet!) #992 (comment) - removes unnecessary(?) permalink yaml in pages headers - fixes a couple errors I noticed in pages text while doing other stuff
- Finished updating /about to include all new GDoc text plus edited past FAQ; moved some past FAQ text into new collab/community/expertise subpages - Added more redirects (many for old blog posts; from this list: #992 (comment))
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."
|
Latest list of to-dos:
|
Completed research and decision, moved remaining tasks to new ticket; closing this as #1013 handles the latter actual move to all-GH |
* replaces links to http praxis site with https * links to praxis charter that used .html at end, producing 404, fixed * fixed all references to http://www.scholarslab.org/grad-student-research/ to point to /blog posts instead * fixed all references to other old WP categories that used to be in the URL for blog posts (see "redirects I did not create" section from this GH issue for which categories those were: #992 (comment))
Noting /realignment branch commit 06f9824 addresses items in this message #992 (comment) under "redirects I did not create", making old posts point to where these posts currently reside instead of using old broken links |
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 actions3. 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 Shane5. 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 site7. 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 belowBackground work (completed!):
Assess if prohibited plugins necessary to siteDone; the plugins we use are allowed by GHPJB wrote Bob 6/13 to doublecheck pointing domain at GHP server allowed;Bob said it's fine!6/13 wrote BW, JB, SL for feedback by 6/30BW wrote back approving, no reply from Jeremy or Shane by deadline so moving aheadPros:
Easy to make repo private (Ask Shane to investigate our making this repo private (ie server hook needs auth info?) #985 )Cons:
Options for SLab website hosting and deployment:
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:
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:
The text was updated successfully, but these errors were encountered: