search

OpenINF / open.inf.is

⚡🐋 The OpenINF portal, other static resources, and more static electricity
https://open.inf.is
2 stars 1 forks source link

🏗️ enabling custom site building & attaining deployment freedom #9

Open DerekNonGeneric opened 4 months ago

DerekNonGeneric commented 4 months ago

🐛 Bug report

Location

Section of the site where the content exists

Affected URL(s):

Description

Concise explanation of the problem

i am/was about ready for merging OpenINF/openinf.github.io#1131 (as stated); however, it will be adding custom Jekyll plugins, which are not supported by our current publishing infrastructure (github pages)

GitHub Pages cannot build sites using unsupported plugins. If you want to use unsupported plugins, generate your site locally and then push your site's static files to GitHub. —https://docs.github.com/en/pages/setting-up-a-github-pages-site-with-jekyll/about-github-pages-and-jekyll#plugins

in essence this issue will try to outline our next steps, which i have experience in solving already, but would like to communicate what all that entails more clearly below since it's not exactly straight forward and would most-likely require custom scripting and hoop-jumping, but it is a well-known work around

DerekNonGeneric commented 4 months ago

we have the following options:

👍 - this is the least-disruptive change 👎 - we must keep the undesirable repo name (OpenINF/openinf.github.io)

👍 - we will finally have the intended repo name 👎 - we might have to do some musical chairs w/ the ci setup and other connected apps

i have not forgotten about the lack of support for 301 redirects that we absolutely must have to unblock https://github.com/OpenINF/openinf.github.io/pull/1152, but i am thinking that we want to do this migration in a few phases (meaning that we do not immediately solve the redirects issue and continue using the gh pages backend initially)

the truth of the matter is that we have crappy options when it comes to servers supporting redirects like we want them (using the _redirects file);

i am thinking we may be able to keep using Netlify — not only for staging/previews, but also for the production site's server (it ain't free/cheap unless i go begging or something)

🔗 Netlify Open Source Plan Policy

DerekNonGeneric commented 4 months ago

Open Source Plan Policy

Netlify loves open source! To show our commitment, we’ve created an Open Source plan to enable projects working on open-source-licensed software to host websites containing information directly related to the community around that software. Our Open Source plan has the same features and limits as our Pro plan, with the addition of free unlimited team members.

To qualify for the Open Source plan, a project must adhere to the following criteria:

  • Includes a license listed on the Open Source Initiative approved license list or a Creative Commons license that includes “attribution” or places the work in the public domain.
  • Features a Code of Conduct at the top level directory of the project repository or prominently in the documentation (with a link in the navigation, footer, or homepage).
  • Must feature a link to our service on your main page, or all internal pages. You have two options:
    • We have premade badges for your convenience, or
    • You may create your own link, which should read “This site is powered by Netlify”, and include a link back to our home page.
  • Must not be a commercial project, whether created by a company or an individual. This prohibition includes commercial support and hosting services.

If you feel your project meets the terms of this policy, please fill out this form for our review.

Examples

Sites qualifying for the Open Source plan might include content such as documentation, change histories, issue trackers, blogs by the development team, and similar auxiliary information. The Open Source plan is intended for projects that welcome open collaboration and reuse of their software and potentially their associated content.

Good examples of projects with the type of site we are targeting are:

The Open Source plan is subject to Section 6 (“Free Usage Tier”) of the Netlify Self-Serve Subscription Agreement. In the event that we discover sites that do not appear to be about open-source-licensed software and/or do not have a link to Netlify, we will inform the site owner of the observed mismatch. > If no response is received, we will downgrade the plan after providing notice.

—https://www.netlify.com/legal/open-source-policy#main

DerekNonGeneric commented 4 months ago

Must feature a link to our service on your main page, or all internal pages.

wow, that seems almost too over-demanding, but it is good to list high-quality sponsorships (btw, not many think Netlify itself is crappy & they have a very good reputation amongst almost everyone i know)

i am just not super content w/ how these types of services normally insistent on using their infra to build our projects while they keep outdated toolchains and deps

work around i had in mind: using github actions to build our projects via ci and deploying that built site to their static site server somewhere (it just needs to support those handy-dandy _redirects files):

main issue (and actually why we've ruled out Cloudflare pages) is that sometimes their toolchains used to build projects are too old for our current setup (if they are up-datable, that is no problemo tho); in the case of Cloudflare pages, that did not seem to be the case when i checked recently (will be double-checking since it seemed absurd)

DerekNonGeneric commented 4 months ago

btw, i have decided that it would be cool to get that corporate sponsorship/partnership and am now working on touching up GitHub Sponsors profile that was sort of a joke before

🔗 https://github.com/sponsors/DerekNonGeneric?preview=true

UPDATE: at least i have made it less-bad now & will get back to the topic on-hand