ER: Unexpected Website Deployment in Forked Repo

[tony1ee]

Emergent Requirement - Problem

Forked Repo of hackforla/website is unexpectedly deployed under the individual's <github-handle>.github.io domain.

Further looking into the problem needed to locate the exact reason of this unexpected deployment.
Preliminary research suggests this happens without any related action taken by the developer and is happening to GitHub accounts without Github Pages set up prior to forking the repo.

Update: further testing suggests the website repo will be deployed every time the fork is synced with upstream, possibly by dynamically triggered workflow pages-build-deployment

Issue you discovered this emergent requirement in

• N/A

Date discovered

04/18/2024
See link to slack discussion below in Resources

Did you have to do something temporarily

• YES
• NO

See Potential solutions [draft] for temporary solution

Who was involved

@tony1ee

What happens if this is not addressed

• Fork data shows approx. 694 forks as of writing. Many (but not all) have published/deployed the site possibly due to this issue. If not addressed, number of published sites will grow as new developers get onboarded.
• Various version of the "HfLA official" websites (some with outdated content and issues not fixed by latest PRs) would be publicly available on the internet, even on a domain other than hackforla.org.
• For individual developer, this deployed site could cause issues if they have set up their own Github Pages site under their <github-handle>.github.io domain
• Potentially causing various SEO issues.

Resources

• [GitHub Docs] GitHub Pages: Unpublishing a GitHub Pages site
• [GitHub Docs] GitHub Pages: Deleting your site by changing the source.
• [GitHub Docs] GitHub Pages: Publishing with a custom GitHub Actions workflow
• Link to discussion thread on #hfla-site Slack channel

unfold to see Slack thread archive

Tony Li

Since the testing are done using the docker image locally and comparison is to the hackforla.org website, is there any use for the <your-github-username>.github.io/website deployment? Though it might cause some conflicts for someone who already has a site at <your-github-username>.github.io.
15 replies

Elliot Kim
Where does it say to deploy to your github.io? (edited)

Tony Li
I think it’s automatic. for example, for your account, it’s already deployed at https://elliot-d-kim.github.io/hfla-website/

Elliot Kim
Thanks for pointing that out, I didn't know! I agree this could potentially cause issues.
Also sent to the channel

Tony Li
looks like you can go to the forked repo then settings → pages to find the button to unpublish,

Fang
@ Tony Li
I'm just commenting on how I see things and this is not the guideline of the website project.
I don't think it will cause conflicts unless their <your-github-username>/<your-github-username> project also has a website folder.
This is how github allows users to publish sites on ghpages: <your-github-username>.github.io/<project-name> . I think it's up to the individual github user to handle such conflicts. Maybe it's good to mention the potential for conflict in case people aren't aware.
The <your-github-username>.github.io/website deployment is a copy of the hackforla website at the point when you updated your gh-pages branch, which may or may not be the same as the current website. So I guess it can serve as a reference website for your current feature branch changes while you're working on it. The current website might have further changes from other devs. If you're at the point of wanting to do a PR, then you should pull from and also compare against the current website. I'm just saying there might be a beneficial use for the <your-github-username>.github.io/website deployment.

Tony Li
@ Fang
Thanks for joining the discussion.
Keep in mind that despite the home page is not every resource in the website is <your-github-username>.github.io/website , not all linked resource is under /website.(e.g. /join for joining) Since both the domain and the root of the website is be different, this deployment of the website can have unexpected errors (e.g. the sponsor logos not displaying because path is 404), so I don’t think it could be used for a reference.
Especially when you already have a personal ghpages website deployed, this can cause broken links and even SEO issues.
Another issue potentially for HackForLA is these different versions of developer websites, some potentially with outdated or inaccurate info (when behind hackforla/website).

Fang
@ Tony Li
I see your point. You're thinking of protecting the user's ghpages deployment from the project. That does make sense.
I was thinking from the hackforla project's point of view. The outdated deployment is not really an issue since the real website is on its own .org domain rather than github.io
I'm not familiar with the sponsor logo paths so you have better info on that.
👍
1

Tony Li
@ Roslyn Wythe
this needs some attention

Roslyn Wythe
@ Tony Li
@ Fang
At one time we considered instructing developers how to use GitHub pages on their forks and PR branches, to do testing as an alternative to docker, and we found a way to fix the problem with the broken paths, but we decided against making us of it because we didn't want various version of the website publicly available on the internet, even on a domain other than hackforla.org.
👌
2

Roslyn Wythe
@ Elliot Kim
did you say that you hadn't enabled GitHub pages on the forked repository? I would be surprised if it was enabled by default, but I guess that is possible

Elliot Kim
Yes, I don't remember enabling it at any point.

Elliot Kim
I just went through some Pre-work Checklists and many (not all) of the recent people to join have the HfLA website on their GitHub pages too, so it doesn't appear to be an isolated incident. (edited)

Roslyn Wythe
OK thank you all. I didn't realize the situation was widespread! I suppose we could instruct developers to disable GitHub pages on their fork of the website repository.
@ Tony Li
Would you be willing to write an ER describing this situation?

Tony Li
sure! happy to!

Tony Li
ER #6689 drafted
@ Roslyn Wythe

Recommended Action Items

• Make a new issue
• Discuss with team
• Let a Team Lead know

Potential solutions [draft]

For current contributors, we can instruct them to:

• Temporarily unpublish website
  A temporary fix could be to instruct developers to manually unpublish the site by going to <github-handle>/website repo settings - pages - unpublish, as shown below.
   
  This will unpublish the website but won't prevent the GHA from being triggered and republishing the site

• Delete GitHub Pages site by changing the source
  Follow the steps on GitHub Pages Docs.
  Settings - Pages - Build and deployment - Source", select "Deploy from a branch" even if the site is currently using GitHub Actions, then Under "Build and deployment", select None as the publishing source, then "Save"
   
  This should prevent the website from being re-published.
  This also won't prevent the GHA from being triggered and republishing the site.

• Alternatively, Disable GitHub Actions
   
  note that this would turn off pages-build-deploy as well as disabling all other workflows from running, so unsure whether this is an acceptable solution.

• Explore Custom Deployment Options
  as mentioned by @elliot-d-kim in this comment below

For future contributors, we can:

• Instruct them (by making changes to CONTRIBUTING.MD) to follow the solution for current contributors mentioned above, after forking the website repo, or
• Prevent workflow from being forked/being triggered in forked repo
  A more permanent solution could be figure out a way to prevent this workflow from being triggered in forked repo.

For inactive developers:

• Notifying past developers
  As @elliot-d-kim pointed out, notifying inactive developers who are affected by this issue might be needed.

[tony1ee]

Please advise on applying proper labels to this ER, thank you.

[elliot-d-kim]

The onboarding documentation could be updated to prevent future instances, but what about current developers? Could there be a change that developers could "pull"? And what about past developers?

[tony1ee]

@elliot-d-kim since the deployment is for the forked repo, I think we need to inform all developers who have forked the website repo of this issue and the steps to unpublish. I do not see a way for us to control their individual repo settings.

[tony1ee]

Update: looks like the temporary fix won't work as initially suggested, since every time the fork is synced with upstream, the site gets redeployed again, seemingly by a workflow triggered automatically.

[tony1ee]

Another possible solution could be to instruct developers to turn off GHA in their workflow, but this would turn off pages-build-deploy as well as disabling all other workflows from running, so unsure whether this is an acceptable solution.

[tony1ee]

Update: looks like the temporary fix won't work as initially suggested, since every time the fork is synced with upstream, the site gets redeployed again, seemingly by a workflow triggered automatically.

Looks like this is expected behavior for GitHub Pages: Per GitHub Pages Docs,

A successful workflow run in the repository for your site will create a new deployment. Trigger a workflow run to redeploy your site.

[t-will-gillis]

Hi @tony1ee - Just starting to look at this but as a first step, you reference a Slack conversation above: please copy that convo to this issue. Slack conversations are lost after a few months so we can't rely on Slack as a record.

[tony1ee]

Based on hackforla/website repo's fork data, there are approx. 694 forks.

many, but not all, of the forks have deployed sites.

[tony1ee]

Proposing a possible temporary solution as mentioned at Deleting your site by changing the source.
Updating it in main comment ...

[elliot-d-kim]

I'm currently exploring custom deployment options.

@t-will-gillis mentioned to me that if: github.repository == 'hackforla/website' can prevent workflows from running on forks. This use of if statements is already present on the main branch in workflows like Schedule Daily 1100 and Update VRMS Data.

However, the pages-build-deployment workflow in its current configuration does not have a workflow file. It's a "default" workflow from GitHub (From the repo, Settings > Pages > under Build and Deployment, Source > Deploy from a branch).

Switching from 'Deploy from a branch' to the 'GitHub Actions' option would provide us with a selection of template workflow files, including one for deploying Jekyll sites. This workflow file would allow us greater customization, including adding if: github.repository == 'hackforla/website' to deploy the HfLA website only on the main branch.

I have a test branch but I haven't yet fully tested switching to the custom configuration. Any thoughts on how appropriate this approach is?

[roslynwythe]

@tony1ee @elliot-d-kim @t-will-gillis I like the "Delete GitHub Pages site by changing the source" option best. Are there any disadvantages to that approach?

[tony1ee]

@roslynwythe It is only a very temporary solution, as I tested just now, after changing the source to "None", a sync with upstream will cause the workflow to run again and therefore website re-published.

(My apologies for wrongly stating "This should prevent the website from being re-published." for this method as mine repo was not behind upstream at the time of writing to do further testing)

main comment has been updated to reflect this discovery.

Might be useful for instructing inactive developers who will not sync with upstream again. But for active developers who still need to sync with upstream, this won't solve it, and a longer-term solution (looks like we need to tackle it from the GHA angle) is needed.

[roslynwythe]

Thank you @tony1ee for testing the proposal to set "default branch" to None - It is surprising, but I had the same results in my fork: after a sync with upstream, the site is re-published! @elliot-d-kim the approach you described above in #6689 (comment) is starting to look like the best approach. @t-will-gillis do you concur?

[ExperimentsInHonesty]

@tony1ee @elliot-d-kim I am sorry this issue has been sitting around so long... Its possible that this solution might work, but it would require a lot of testing and some documentation about the lift that would be required to deploy, maintain, etc. And any potential downsides. Are either of you interested in continuing that exploration?

[elliot-d-kim]

Hi, thanks for coming around to this. While I'd love to work on this, I have my hands full with some other priorities for the next month. I'd be happy to stay tuned and be a point of reference for whoever picks up this issue!

[ExperimentsInHonesty]

@elliot-d-kim it sounds like you won't be working on this, but are happy to be a resource to whoever does. I will check again with @tony1ee to see if he wants it. Otherwise, we are going to close this as unplanned.

[tony1ee]

@ExperimentsInHonesty Apologies for the delayed response. While I’d love to see this resolved, I don’t believe I have the necessary expertise to work on the solution, especially the custom deployment options GitHub Actions solution, as it seems to be the most promising.

[ExperimentsInHonesty]

@tony1ee Since we don't currently have someone with the expertise to own this issue and take to the finish line. Would you be willing to write up a decision record about this work, so that we have a summary that we give to that person if they ever show up?

This is a record in the Decision Records on Solutions Not Implemented.

Issue

Problem Statement

Potential Solution

Feasibility Determination

[tony1ee]

@ExperimentsInHonesty Sure, I would be glad to do that!
I will create a new wiki page following the template, and have it linked at the end of Decision Records on Solutions Not Implemented
ETA: Sunday 29th.

[ExperimentsInHonesty]

@tony1ee please put the draft in a comment here and then also edit this page to add a link to your comment https://github.com/hackforla/website/wiki/How-to-Contribute-to-the-Wiki

[ExperimentsInHonesty]

add the label ready for dev lead and move to the questions column when you are done

[tony1ee]

(Draft) DR: Preventing Unintended GitHub Pages Deployment on Forked Repositories

This is a record in the Decision Records on Solutions Not Implemented.

Issue

• ER: Unexpected Website Deployment in Forked Repo #6689

Problem Statement

Unintended deployments of the hackforla/website repository on forked repositories led to unexpected website publication under developers' personal GitHub Pages domains. This behavior occurred due to GitHub Pages’ default setting to publish forks automatically when users sync their repositories with the upstream main branch.

Potential Solution

While manual un-publishing is possible, a more permanent solution is to use conditional deployment GitHub Actions that only trigger on the main hackforla repository, ensuring forks do not auto-deploy on forks. Replacement of the existing page-build-deployment workflow with a custom workflow is needed to check repository origins before initiating deployment.

Feasibility Determination

• Manual un-publishing relies on individual compliance and may be inconsistent.
• Custom deployment GitHub Action offers automation but requires thorough testing and detailed documentation on deployment, maintenance and potential downsides.
• This issue will be deferred until a developer with the necessary capacity and availability can take on this work.

[ExperimentsInHonesty]

@tony1ee Thanks for the draft. I'll add this to our dev/pm agenda for next Monday in case you don't get a sign-off on this draft before then.

[JessicaLucindaCheng]

@tony1ee LGTM! Thanks for writing the decision record!