I use a combination of GitHub Actions and GitHub Pages to generate and host a number of "semi-static" sites. That is sites that are updated regularly during the day using scheduled GitHub Actions. Here's one example.
The repos contain the HTML pages which make up the site, but those pages are all generated by GitHub Actions. There's no point in updating those files in a pull request as the changes will be overwritten the next time the site is regenerated.
I mention this in the README for the repos, but I still get PRs from people that change the output files, rather than the templates that are used to build the files.
To make my life that little easier, I'm wondering if there's a way to mark these files so that any PR that changes these files is automatically rejected with a polite comment explaining the problem. Alternatively, is there a way to mark these files so that GitHub knows they shouldn't be included in PRs?
It's an interesting idea so I tried and it worked!
I had to use pull_request_target as the event for forked repositories. More information can be found at https://github.blog/2020-08-03-github-actions-improvements-for-fork-and-pull-request-workflows/.
I've picked opened and reopened for the activity types, however please find more from here if you need it: https://docs.github.com/en/actions/learn-github-actions/events-that-trigger-workflows#pull_request
For now, this github action is triggered when the file untouchable_file is included as a change in a pull request, but if you need more complex path filter matching, see here: https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet
name: Test workflow
on:
pull_request_target:
types: [opened, reopened]
paths:
- 'untouchable_file'
jobs:
test:
runs-on: "ubuntu-latest"
steps:
- uses: superbrothers/close-pull-request#v3
with:
comment: "hi. please do not touch 'untouchable_file'."
Related
Is there a way to set repo settings inside a file so that GitHub displays them on the main page?
Input (e.g. .github.yaml in main branch)
Output (repo main page)
meta_data: description: JDK main-line development website: https://openjdk.org/projects/jdk topics: [ java, jvm, openjdk ]
I'm looking for an answer without calling GitHub APIs.
I'm looking for an answer without calling GitHub APIs.
And yet, a call to updating a repository API would certainly be involved, through a GitHub Action.
You can setup such an action triggered only by your file, in the main branch:
on:
push:
branches: ['main']
paths: ['.github.yaml']
And use directly a gh repo edit -d '...' call, since the GitHub CLI I is preinstalled on all GitHub-hosted runners.
That way, each time you modify the .github.yaml file, you can regenerate the About message on your repository.
can we configure our github actions yml file such that whenever we make commit to our repository, it automatically prepares the empty package.xml file with the components commited and deployment begins to the target org?
I know how its done when we have packaged.xml file along with the componets in it,but here the package.xml file should be empty and whenever we commit our changes to the repository, yml automatically prepares the components to be deployed based on the commits in the empty package.xml file and then finally deploys to the org
For triggering event you'll need to define "on" in the yml. You can start with what's in https://github.com/trailheadapps/lwc-recipes/blob/main/.github/workflows/ci.yml - on any commit/pull request to main branch unless it's just a readme change. And allows for manual triggering too
on:
workflow_dispatch:
push:
branches:
- main
paths-ignore:
- 'sfdx-project.json'
- 'README.md'
As for actual commands...
What's your Github repository's format? Old school metadata api format (with package.xml, Account.object containing dozens of fields, listviews, validation rules) or new source tracking format (Account is a folder, every single field gets its own small xml file, most important directory is probably "force-app/main/default")?
You should be able to call sfdx force:source:convert -d mdapi in your github action to create a temp directory called "mdapi". If you're making a managed package read up about the "-n" option. It will contain your changes but converted from source to mdapi format.
There are things it will not do that a hand-crafted package.xml would (description, post install class) - but again, these tend matter when you make managed packages, for normal usage you should be fine.
After convert try sfdx force:mdapi:deploy -d mdapi -l RunLocalTests -w -1 -c (metadata format deploy, which directory, which tests, wait as long as it's needed, just validate, don't really deploy)
There are sfdx plugins to make it smarter (deploy a delta between 2 commits, not a full project every time). https://wiki.sfxd.org/books/sfdc-tools/page/notable-sfdx-plugins-and-resources
I'm fairly new to GitHub and I've been trying to get the GitHub Wiki associated with a project to get the content from the main repository with no success.
Online there are guides on how to do this on Microsoft Azure here, but for some reason, I cannot find anything similar for GitHub. I am not sure where to ask this question so I came to the trusted StackOverflow community.
Basically I have a repository where we are uploading a series of markdown documents (see giovannellilab/protocols) and I would like the content of the wiki for the same project to be updated with pages coming from the repository. Each markdown file in the repository becomes its own wiki page. Ideally, the wiki will get automatically updated every time we push something new to the repo or we merge a new pull request.
So far I have not found an easy to implement a solution.
I've also tried to use a GitHub Action found in the marketplace, SwiftDocOrg with no success. I'm new to GitHub-actions and even follwing the guide I could not make this work.
Here the content of my .yml page:
- name: Publish to GitHub Wiki
uses: SwiftDocOrg/github-wiki-publish-action#1.0.0
with:
# A path to the directory of files to publish
path: giovannellilab/protocols
The action is failing each time (obviously something is wrong/missing, but I cannot figure out what).
Any suggestions on how to make it work in GitHub?
Any other place where I can host documentation pulling directly from a GitHub repository?
Any other better way to implement this?
Thank you very much,
Don
I need to host the documentation of multiple versions of my project (say 1.0, 2.0 and 3.0) and all are active (documentation)branches and we shall keep on adding improvements to all of these.
Is it possible to use GitHub pages for this purpose?
Appreciate any help on this.
This is feasible using Github Actions along with a static site generator (SSG) of your choice such as VuePress, Gatsby, Jekyll etc.
In its simplest form, create a GH action to generate the static site folder of the branch/release, then push the folder to corresponding folder in the branch pointed to by GH pages, say gh-pages. One of the branches/releases should be pushed to root. GitHub Pages Deploy Action can be helpful. Lastly add a dropdown list of versions to your static website pointing to the matching folder. The list of items can be statically maintained or dynamically populated using GitHub API. The selected item depends on the current URL path.
Example:
To provide multi-version docs for software product NotifyBC,
input - docs folder of the product created by VuePress
output - gh-pages branch
GitHub action, with main branch pushed to root of gh-pages branch and releases pushed to version folder
dynamically populated dropdown list implemented in Vue component
rendered site powered by GH pages
You can have a look at gh-pages-multi.
It is a small nodejs tool I wrote to push different versions of docs to subdirectories in a gh-pages branch. It also generates a index.html file listing those subdirectories.
It is fairly easy to integrate in a CI workflow if you want to automate building and pushing the docs.
Also note the "--no-history" option that will prevent bloating the git repo if your docs contain some built files or binary assets.
These other answers over-complicate things. As #jhpratt suggests in the comment, you can just copy the code corresponding to a version of your site you want to deploy to a dir (labelled e.g. v1.0) within the dir that you deploy to gh-pages. You then access the version with https://your-name.github.io/your-repo/v1.0/.
Of course, depending on the type of site you're building you may have to worry about the content of <base href="..."> tag, etc., for each version, but you need to worry about this tag in any case since github pages do not deploy to the url root.
I have a project on AppVeyor that I want to build in two (or three) different scenarios:
Anytime it's on the master branch no matter which files changed, but not a pull request
If it is a pull request on the master branch when certain files have changed
(Maybe if it's on a different branch when certain files have changed)
Is there a way to configure appveyor.yml to do this? I'm aware of how to use APPVEYOR_PULL_REQUEST_NUMBER in one-liners, but I want to be able to apply it to the entire appveyor.yml, and combine it with the only_commits: options.
You can create 2 projects on AppVeyor connected to the same GitHub repo:
For the first project got to GitHub repo settings, find Webhook connected to this project and uncheck pull request
For the second project set only_commits for those certain files according to commit filtering doc
Optionally, for the first project set skip_commits for the same files according the same commit filtering doc, to eliminate duplicate builds.