Giters

skywarth / vite-github-pages-deployer

Deploy your Vite application to Github pages, plug-and-play.

Home Page:https://github.com/marketplace/actions/vite-github-pages-deployer

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

auto detection of CNAME / public_base_path ?

gregsadetsky opened this issue · comments

commented

hey,

thanks for making this workflow, it's been incredibly useful to deploy Vite projects quickly!!

one question -- when I do deploy to a domain (or subdomain) and the public_base_path is /, I typically forget first to set that value, and then have path errors that I realize are deployment/vite related

is there any way to auto detect the CNAME and/or better - the deployment path from github pages..? without making it fragile, could you detect a "non standard" i.e. CNAME value in the actions/deploy-pages page_url value... and do something about it? I realize there's probably a bunch of possible pitfalls!

thanks again!

commented

Hey there,

I appreciate the feedback. So glad my package was somewhat of a help 🥳. Thank you for using it!

As for your question: I'm a bit lost on how can I assist you, I'm trying to grasp your requirement so I can be of help, but couldn't really understand it. Here's what I gathered from your request:

I understand that you need some automatic/default value for the public_base_path input of the package. It is actually optional, so if you don't pass any value for that input, it just assumes your repo name as your sub-directory (not subdomain). So if you don't give a value for this input, for your rctv-app-list-of-signins repo for example, it would resolve to /rctv-app-list-of-signins, which is expected because github will be serving your page at https://gregsadetsky.github.io/rctv-app-list-of-signins/.

If you could describe your expected feature, maybe through a use-case, I would be more than happy to assist you. 👍

commented

for sure, sorry for not describing it clearly!

the "default" use case, as you describe it, is to deploy to greg.sadetsky.github.io/REPO -- in which case, your workflow does the right thing and sets public_base_path to the correct value

however, I also sometimes deploy directly to domains or subdomains i.e. www.example.com. I do so by adding a CNAME file to my repo with the value (say example.com), and then setup Github Pages to deploy to that domain (it will then validate that the domain points to GitHub, provision an SSL certificate, etc.)

the problem is that the Vite workflow does not pick up on that and still uses the repo name for public_base_path. and that, as you can imagine, leads to trouble :-) i.e. the JS code tries to load files from /REPO/... when all of the files have actually been deployed to /

let me know if this is clearer or not. also happy to deploy an example vite project to a subdomain to show you if that's easier/clearer. thanks!

commented

Thanks for the explanation.

Oh I see. So you're serving your app on github pages via a custom domain. Well that is intriguing, I didn't knew about it. It is certainly worth taking a look at. Learnt something new today thanks to you!

In the case of custom domain for github pages: you add a CNAME file to your repo root with some IP addresses inside. Then you configure repo settings and set the custom domain there, yeah ?

If that's the case, I think we could definitely set up some expansion for your requirement. Here's couple of options I could think of: (pseudo-code) for action.yml changes

  1. Deciding default public_base_path based on the existence of CNAME file:
inputs:
  public_base_path:
    required: false
    default: "/${{ (REPO_ROOT.HAS.CNAME) ?  ''  : github.event.repository.name }}"

As you can see, with something like this public_base_path would resolve to '/' if the repo in question has a CNAME file at the root, otherwise it would simply resort to repository name.

  1. Deciding default public_base_path based on the value of custom domain setting:
    I'm not sure if this one is available/permitted in github actions API but if it is, we could simply fetch the custom domain (defined in repo settings) and if that custom domain value is not null, then we would use it otherwise resort to repo name.
inputs:
  public_base_path:
    required: false
    default: "/${{ (REPO.SETTINGS.PAGES.CUSTOM_DOMAIN!==null) ?  ''  : github.event.repository.name }}"

First option seems more viable, but a bit invasive. On the other hand second option is the perfect fit but not sure if it is available/permitted. Either way I think it's possible to address your needs.

I'll take a crack at it on weekend, i will be developing the changes in a separate branch so you lock your action usage to that specific branch (rather than master) so we don't disturb the existing users. Stay tuned.

Meanwhile, feel free to open up a PR if you would like to contribute and/or you're in a rush.

commented

Thanks a ton for looking into this! On one hand, I now feel bad that I'm making you look into all of this... maybe I can just set public_base_path to / myself and be done with it? 😅

But on the other hand, probably that defaulting to a "better" value when github pages is deploying to a domain (via cname) might be a good idea? It would definitely solve my problem of adding your vite workflow, and then things would just work automatically!

The other thought I have is that definitely for option 1, you wouldn't want to introduce a breaking change... i.e. is it possible that someone is using your workflow, and a custom CNAME, and... didn't change the public_base_path value but somehow made their deployment work (by modifying their vite configuration file?) I obviously wouldn't want the "better" version of the workflow to assume that because a CNAME file is there (like you say it's a brittle test), or even if github pages is enabled to deploy to a domain, to do things differently... I'm just unsure whether that's enough of a signal to change public_base_path automatically?

I just did a quick test, and there seems to be at least 1 API call that gives some info re: domains/CNAME:

https://docs.github.com/en/free-pro-team@latest/rest/pages/pages?apiVersion=2022-11-28#get-a-dns-health-check-for-github-pages

I specifically did the following call with two repos -- one which is deployed to gregsadetsky.github.io/REPO and the other to a domain:

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer (personal token)" \
  -H "X-GitHub-Api-Version: 2022-11-28" \
  https://api.github.com/repos/gregsadetsky/REPO/pages/health

for the .github.io/repo, I got this:

{
  "message": "There isn't a cname for this page.",
  "documentation_url": "https://docs.github.com/rest/pages/pages#get-a-dns-health-check-for-github-pages"
}

while for the other repo (deployed to a domain), I got either an empty JSON result (I think ... because the DNS check wasn't done? but it's strange that the response was just { }!) or a response with a ton of info re: CNAME/domains:

{
  "domain": {
    "host": "2600.greg.technology",
    "uri": "http://2600.greg.technology/",
    "nameservers": "default",
    "dns_resolves": true,
    "is_proxied": false,
    "is_cloudflare_ip": false,
    "is_fastly_ip": false,
    "is_old_ip_address": false,
    "is_a_record": false,
    "has_cname_record": true,
    "has_mx_records_present": false,
    "is_valid_domain": true,
    "is_apex_domain": false,
    "should_be_a_record": false,
    "is_cname_to_github_user_domain": true,
[... snip ...]

last thing sorry :-) the one thing is that the personal token that I used for the dns health check API call above needed to have administrative:write and pages:write permissions... which is a bit intense? I don't suppose that the GITHUB_TOKEN that the github actions workflow has access to has these permissions..?

that's it for now :-) thanks again for your help!

commented

Hello there,

I did some changes to the original action.yml to support alternate public_base_path value if CNAME (for gh pages custom domain) is present.

In order to not disturb the users of the package, I applied the necessary changes in a branch: custom-domain-expansion. I did some tests and it seems to be aligning well with your requirements. You may see the current state of action.yml here

I tried as much as possible to enable backwards compatibility in order to allow smooth transition into master.

Here's how it works now:

  • If the user provides any public_base_path input value via with: statement, it will be used regardless of CNAME or other stuff.
  • If no public_base_path input is provided to the action, then:
    • If the repository root has a file CNAME, then public_base_path will default to '/'
    • Otherwise, public_base_path will default to '/{{repo_name}}'

So in other words, there is 2 different default values depending on the context. Even though I did test different configurations in a repo of mine (https://github.com/skywarth/country-routing-algorithm-demo-vue) and noticed no problems, would you mind testing the cases that I've stated above (if conditions) ?

You may lock your package version usage directly to this new branch custom-domain-expansion in your action YAML file like so:

- name: Vite Github Pages Deployer
  uses: skywarth/vite-github-pages-deployer@custom-domain-expansion
  id: deploy_to_pages

I hope this suffices for your case. Let me know when you try it in your workflow/pipeline and how it fares. If it works out for for your case, and tests show no problem then we can merge to master and publish a new release.

commented

Amazing, this works! I just tested it by creating 2 repos with the same Vite starter code. Both repos were deployed to different domain names (I created two different subdomains).

The repo that ended up working used skywarth/vite-github-pages-deployer@custom-domain-expansion, while the other repo (which didn't work) used the default @master branch i.e. the current action code.

Result:

Thanks a ton! This is really great! :-) I really really appreciate that you took the time to fix this.

commented

Splendid. I'm happy to hear that it resolves your case. I'll be doing a bit more testing then merge into master and publish a new release. Thank you for taking the time to do tests.

I'll close the issue after publishing the release.

Have a good one

commented

Published a release: https://github.com/skywarth/vite-github-pages-deployer/releases/tag/v1.3.0

Moreover, added an acknowledgement section in the documentation for your contributions: https://github.com/skywarth/vite-github-pages-deployer/blob/master/README.md#public-base-path-ack

Enjoy!

commented

Amazing, thank you so much!!

And checking this again one last time, I just re-published the site from my previous comment (the one that was broken) and now it suddenly & immediately started working (since the CNAME detection is now on by default and worked exactly as intended)

Thanks again!!