Will cancel default GitHub build and deploy workflow, triggering email notification on each push

[fladd]

Describe the bug

This action seems to run in addition to the default "pages-build-deployment" GitHub action that gets automatically added when GitHub pages are activated, and that cannot be deleted or permanently disabled (it will enable itself again).

As can be seen in the following screenshots, after each push, the default action runs, but then gets interrupted "since a higher priority waiting request for 'master' exists":

This cancellation triggers an email notification that an action failed. Every time "github-pages-deploy-action" runs:

Reproduction Steps

• Add a workflow as described in the "Getting started" section
• Two actions will start to run:
  1. "pages-build-deployment" (the default GitHub pages action)
  2. "github-pages-deploy-action"
• "pages-build-deployment" will be cancelled
• github-pages-deploy-action" will finish
• "pages-build-deployment" will run again and finish

Logs

Tested with workflow:

name: Build and Deploy

on:
  push:
  
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    if: |
      contains(github.event.head_commit.message, '[build]')
    concurrency:
      group: ${{ github.workflow }}
      cancel-in-progress: true
    steps:
    - name: Check out repository
      uses: actions/checkout@v2
    - name: Set up Python
      uses: actions/setup-python@v2
    - name: Install dependencies
      run: |
        python -m pip install -U pip
        pip install setuptools wheel
    - name: Install StuffPages
      run: |
        python -m pip install StuffPages
    - name: Build
      run: |
        stuffpages build
    - name: Deploy
      uses: JamesIves/github-pages-deploy-action@4.1.7
      with:
        branch: master # The branch the action should deploy to.
        folder: docs # The folder the action should deploy.
        target-folder: docs # The folder to deploy to.

[JamesIves]

This is likely occurring because you're not using Jekyll, which is fine, there's just another step you need to take. In your deployment branch/folder, in this case looks like master/docs, create an empty file with the name of .nojekyll. Much like the CNAME file this is protected from cleanup jobs clobbering it on each deploy so you can commit it directly, or you can make it part of your build job.

The reason this is necessary is because GitHub Pages has a built-in Jekyll compiler that is used to generate documentation websites. I can't imagine it's used all that much these days but it still exists. By adding that file it will tell GitHub Pages that it's not a Jekyll site, and it will cease attempting to compile with it, thus stopping the emails.

Let me know if that works.

[fladd]

Thanks for the response @JamesIves. I actually do have a .nojekyll file (in both master and master/docs). So I don't think the issue is related to me not using Jekyll. Any other ideas how to disable this default GitHub pages workflow?

[JamesIves]

For some additional context the reason the github-pages build job exists to begin with is because GitHub runs its own job once content has been pushed to the branch designated as the GitHub Pages branch. This job essentially "deploys" it onto their server from the repository (think FTP, but probably not FTP). It's sort of a two pronged thing where this action handles the initial paperwork, and once it makes it to the branch GitHub takes over and makes it go live. The job is meant to be hidden and run behind the scenes so disabling it wouldn't really do much good. Without that job your page would never update.

What just occurred to me is that you're essentially creating a push on top of the same branch/folder. You're deploying the master/docs folder to the master/docs folder. You're essentially pushing the built source for your docs back onto your uncompiled docs, which is going to cause multiple deployments to fire on top of each other and create a deployment loop. You may instead want to push your compiled docs to a different branch, or host your uncompiled docs in a different folder within the master branch. The following example will work if you were to host your uncompiled docs in the src/docs folder.

    - name: Deploy
      uses: JamesIves/github-pages-deploy-action@4.1.7
      with:
        branch: master
        folder: src/docs # Host your uncompiled doc source code here
        target-folder: docs # Push your compiled docs here

This should hopefully prevent GitHub Pages from stacking up these jobs and prevent the emails. Let me know if that works.

[fladd]

Thanks for the explanation. I changed the structure of the repository according to your suggestion. However, the situation remains the same. The GitHub default build and deploy action is interrupted and I get an email that it failed.

The repository in question is this one: https://github.com/fladd/floriankrause.org.

[JamesIves]

Aha, I see the issue here. I forked your project and kicked off some builds, prior to this I setup GitHub Pages so it runs on the master branch within the docs folder as I believe this is what you've got set too. The configuration can be found below:

---

This is an example of a commit to your README within src without [build] in the commit name. As expected the first build stopped due to the if statement in the workflow, but pages-build-deployment still ran for some reason even though the commit was made in src and not docs.

---

When you combine this with a commit with [build] in the name, the same thing happens as the first commit even though the commit didn't occur in the docs directory, but instead in src:

---

Once the deployment job finishes from this action and makes the commit to docs for you it fires off the second pages-build-deployment job which is expected:

---

Because of this the second job cancels the first, which results in the build failure and an email being sent:

---

Ultimately I believe this is an issue you may need to email GitHub Support over as it seems to be a bug with the GitHub Pages builder. I'm not sure why the pages-build-deployment task is running when you make a commit that is not the source folder for GitHub Pages. I would expect any commits made outside of {root}/docs to not fire this job, and the doubling up of builds from this job is what is causing the environment failure.

Sadly I don't have any contacts at GitHub but please feel free to direct them to this issue if you write into support!

[JamesIves]

With that being said if you don't need to have your current structure, and you wish to avoid this issue entirely, you can simply change your GitHub configuration within Settings to point GitHub Pages to the gh-pages branch and modify your workflow like so:

name: Build and Deploy
on: [push]
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    if: ${{ contains(github.event.head_commit.message, '[build]') }}
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Set up Python
        uses: actions/setup-python@v2
      - name: Install dependencies
        run: |
          python -m pip install -U pip
          pip install setuptools wheel
      - name: Install StuffPages
        run: |
          python -m pip install stuffpages
      - name: Build
        run: |
          stuffpages build src
      - name: Deploy
        uses: JamesIves/github-pages-deploy-action@4.1.7
        with:
          branch: gh-pages
          folder: src/docs
          target-folder: docs

If you change the workflow first the action will handle the branch creation for you, and then you go make the modifications here:

---

With this you would:

1. Make changes to your docs on the master branch.
2. The action will build the changes and commit them to the gh-pages branch.
3. The pages-build-deployment job won't double up as you're not making a commit to the same branch that you're deploying from. (Even if it's outside of the gh-pages source).

[fladd]

Thanks so much for taking the time to look into this and explain in so much detail! Really appreciated! I will change the structure to the one you suggested.