-
Notifications
You must be signed in to change notification settings - Fork 37
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
Skip the 'build_html' job on repository forks #515
Skip the 'build_html' job on repository forks #515
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is better than the situation now (so approved). But, I wonder if it wouldn't be even better if possible to formulate it "if: a gh_pages branch exists" to make it possible for people to recover the main repo behavior (which can be useful also for forks) without having to add diverging commits to the repo.
I am not sure if the check for the branch existence can be carried out in the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
New version looks fine to me, the only real test will be merging it...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, lets merge this. But if we set up a separate repo for building and publishing the html version, this may end up not being used here anyway.
Unfortunately, it seems that any non-zero status terminates the job so the job still fails on forks without this branch. I think
should work, but I should probably test it first before submitting another PR. |
Ok, this approach does not seem to work in general. Exiting from the "Commit to gh-pages" job with a zero status results in the "Push changes" job still getting executed (and thus creating a "gh-pages" branch on the fork, but without the HTML pages). I will leave this alone unless the separate repo approach does not work out. |
Ah, the following steps would have to be updated as well to do nothing. So, should we revert this merge? |
We probably should since it is a bit misleading (comments do not match the actual behaviour). Is there an easy built-in way to do so in GitHub? |
The merge icon in this PR thread had a "Revert" button. I clicked that, and it created a revert PR. |
The 'build_html' job fails on repository forks that do not have the
gh_pages
branch. This PR modifies the job so it is only run on the originalMaterials-Consortia/OPTIMADE
repo.