Prepare deployment to move to another service

[sudojunior]

Truth be told, GitHub pages has a limited scope with the plugins it allows. It would be worth a look to see what could be done about deploying to Netlify or Vercel and then expand the plugin directory to use more efficient data throughput. Moving to another platform would also mean a GitHub token is required to query the API or remove the github-metadata altogether until a reasonable solution can be devised.

• [ ] Removal of gems
  • [ ] jekyll-gist
  • [ ] jekyll-github-metadata
  • [ ] github-pages
• [ ] Test deployment for additional jekyll gems and/or custom plugins?
  • [ ] Vercel
  • [ ] Netlify

Additional notes

Getting the _sass directory to work may turn out to be quite a task... if I do it wrong.

Might be worth a clean sweep of the directory to make sure the environment isn't polluted, normalize.css is imported on every build which turns out to be the github-pages gem doing that in the background.

{% seo %} tag generates the metadata for each page, but may also collide with custom properties if implementation is needed. Duplicate SEO tags may affect the way that search engines see the page or the site as a whole, or the page may pick the first one available.

[sudojunior]

It may be possible to rework the site.github metadata injection to work directly with the project (possibly to site.git or implementation into site.github, secondary RFC to cover what data is injected into the object - which will probably include a markup of what data is available and what data is needed). The possibility of this working is unknown considering how Jekyll restricts direct reference of pages.

It's possible to obtain additional data from the GitHub API for user and commit data, but builds may be limited to the number of requests that can be made per hour / per day. (GitHub API Docs on Ratelimits)

(Self-observed) Unauthenticated requests: 60 requests per hour

Server-to-server requests (Normal limits):

• 5,000 requests per hour
• More than 20 users another 50 requests per hour for each user
• More than 20 repositories another 50 requests per hour for each repository
• Overall maximum at 12,500 requests per hour

User-to-server requests (Normal limits):

• 5,000 requests per hour and per authenticated user (quota is shared for the user across all apps)

Not that this causes any immediate concern for requesting data on each build of the site, but that the data may be requested more and more as the site grows in size. (It should only be requested once per site build, but that eventually grows overtime with each pull request and merge made onto HEAD.)

---

Usage notes (/repos{/owner}{/repo}

• payload.name repository name
• payload.full_name combination of owner and repo name
• payload.private is the repository private?
• payload.owner the github actor that owns this repository (ref to user object
  • payload.owner.login
  • payload.owner.avatar_url can also be achieved using the jeykll-avatar gem
  • payload.owner.html_url user friendly reference to the user's github profile
• payload.html_url
• payload.description
• payload.fork
• payload.created_at
• payload.updated_at
• payload.pushed_at
• payload.stargazers_count
• payload.watchers_count currently reports more than there actually are?
• payload.open_issues_count
• payload.license
• payload.forks

Usage notes (/repos{/owner}{/repo}/issues)

• payload[i].html_url
• payload[i].number
• payload[i].user (ref: GitHub Actor)
• payload[i].labels
• payload[i].state
• payload[i].locked
• payload[i].assignees
• payload[i].milestone
• payload[i].comments int
• payload[i].created_at
• payload[i].updated_at
• payload[i].closed_at
• payload[i].body

Usage notes (/repos{/owner}{/repo}/commits)

• payload.sha is the commit ref
• payload.commit is the commit object
  • payload.commit.author refers to actor of the commit
  • payload.commit.commiter refers to origin of the commit
  • payload.commit.message
  • payload.commit.url is the API path to said commit
  • payload.commit.comment_count
  • payload.commit.verification.verified
  • payload.commit.verification.reason`
• payload.author is the GitHub author reference
• payload.commiter is the GitHub committer reference
• payload.parents refers to any commits as the inherriant parents of the current scope

---

• /repos/:owner/:repo
• /repos/:owner/:repo/forks
• /repos/:owner/:repo/collaborators
• /repos/:owner/:repo/contributors
• /repos/:owner/:repo/commits{/sha}
• /repos/:owner/:repo/issues{/number}
• /repos/:owner/:repo/pulls{/number}
• /repos/:owner/:repo/events

[sudojunior]

After testing the possibility and likelihood of the custom plugins being both successful and effective at what they would be made for, it leads to the decision that remaining on GitHub is better for the project's continued maintenance.

That said, there are still a lot of opportunities with the _include and _layout folders. To start with, the structure of each folder should be based on a category (if a 'module' is to be used in said category only or to group off-site / iframe components together in the /embed folder).

This shall be closed, but I look forward to the day that I might return to this once more.