Skip to content
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

Customize the directory to serve from #42

Open
Tbhesswebber opened this issue Apr 25, 2023 · 3 comments · May be fixed by #81
Open

Customize the directory to serve from #42

Tbhesswebber opened this issue Apr 25, 2023 · 3 comments · May be fixed by #81
Labels
documentation Improvements or additions to documentation enhancement New feature or request

Comments

@Tbhesswebber
Copy link

Our Github Pages configuration is set up to serve from a subdirectory and there is currently no documented way to address this with pr-preview-action.

Example:

Preview Deployment Action

      - name: Deploy Preview
        uses: rossjrw/pr-preview-action@v1
        with:
          source-dir: docs
          preview-branch: gh-pages
          umbrella-dir: docs/pr-preview
          action: auto

Deployment Action

      - uses: JamesIves/github-pages-deploy-action@v4
        with:
          folder: docs
          target-folder: docs
          branch: gh-pages
          clean-exclude: docs/pr-preview

With the above configurations, we end up with everything correctly being saved to the docs directory.  The generated preview link is /docs/pr-preview/pr-xx.  I can delete the /docs path part and see the preview just fine, but the generated link shows a totally valid 404 because we are serving directly from the docs directory that things are being saved to rather than serving from the root directory.

@rossjrw
Copy link
Owner

rossjrw commented Apr 25, 2023

Deploying documentation to docs/ on the main branch vs deploying it to the root directory on the gh-pages branch are typically two different methods of isolating GitHub Pages deployments from the rest of the codebase. I'd say it's unusual to see a deployment to the docs/ directory on the gh-pages branch - is this setup definitely intended?

A more traditional approach would be to copy docs/ on your feature branch to the root of the gh-pages branch:

# Preview
      - name: Deploy Preview
        uses: rossjrw/pr-preview-action@v1
        with:
          source-dir: docs
          preview-branch: gh-pages
          umbrella-dir: pr-preview
          action: auto
# Main deployment
      - uses: JamesIves/github-pages-deploy-action@v4
        with:
          folder: docs
          target-folder: .
          branch: gh-pages
          clean-exclude: pr-preview

That would probably be easiest and more in line with the 'standard' approach.

But assumptions and principle aside, if you really do need to deploy from docs/ on gh-pages and you're using the root dir on gh-pages for something else, then you're right - there's currently no way to do that. The variable used for the deployment target dir is the same as the one used to construct the URL:

target-folder: ${{ env.targetdir }}

:rocket: Deployed preview to
https://${{ env.pagesurl }}/${{ env.targetdir }}/

The long-term solution to this would be to add a parameter that indicates what directory Pages is being served from in that repo, as you originally suggested.

@rossjrw rossjrw added documentation Improvements or additions to documentation enhancement New feature or request labels Apr 25, 2023
@Tbhesswebber
Copy link
Author

We can definitely get around this by changing configurations in GH, but I think this is still a valuable feature to add for anyone who doesn't have easy access to the repo settings or a person with repo admin access.

@RedSparr0w
Copy link

RedSparr0w commented Feb 9, 2024

+1 for this, even if it was just a separate input which would replace the partial string of umbrella-dir.

          umbrella-dir: 'docs/preview'
          pages-base: 'docs/'

then on the output just replace any instance of pages-base in umbrella-dir before sending the url.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants