Error log
Liquid Exception: Liquid syntax error (line 6): Unknown tag 'include_cached' in /_layouts/post.html
I am currently making a blog by forking this project at https://github.com/hydecorp/hydejack.
I've tried several methods for 2 days, but it doesn't work. Locally it's fine, but when I build I get an error.
this is my project
https://github.com/JangHwanPark/JangHwanPark.github.io
I tried changing config.yml and layout to md file. I also tried deleting the repository, but it didn't work.
When you build the way you do, the "classic" way (as opposed to using an action), GitHub uses a fixed configuration and a list of whitelisted plugins (visible here). It really only includes the github-pages gem, which includes all other dependencies. Your Gemfile is ignored for the build; among other things, this means the build uses Jekyll v3.9.2, and not v4.1 as in your Gemfile.
There are two approaches:
Stick with the "classic" experience. I recommend you make your local environment match that; the Gemfile simplifies to
source "https://rubygems.org"
gem "github-pages", "~> 227", group: :jekyll_plugins
Don't forget to run bundle install after you've updated the Gemfile so the lockfile gets updated, too.
You'll have to update _config.yml to include your theme via the remote-theme plugin, and add the include-cache plugin to the plugins list.
This closely matches what the docs for your theme also recommend.
Switch to a custom GitHub Actions flow to deploy your page. There is a starter workflow for Jekyll; using that should get you most of the way there. You might still have to specify remote_theme in the config instead of theme, unless you copy the entire theme into your repo.
Doing this lets you use any gems you want, and any Jekyll version you want.
Related
I've developed a composer package that's included into many Github repo Laravel projects. It's set to a specific version, but even if I make it slightly looser and set the patch version to be a asterisk for the patch version I still need to run a composer update in the project that requires the package so that when running composer install on a server it installs the correct version.
The issue I'm facing is that when I release a new package version, I've got to run composer update locally, say 15 times each for 15 projects, then commit all 15, and open pull requests for all 15 etc making the process incredibly slow.
Is there a better way to handle composer update, maybe I need to develop a little CLI application to communicate with the Github api to open PRs and merge them?
What you are describing is exactly what's expected and intended to happen. Full projects with commited lock-files are supposed to install the locked version unless updated.
You could use something like this composer update action to run regularly and create commits when necessary, or work with the GitHub provided Dependabot.
But if this is not coupled with a robust test suite and finely tuned version constraints, you could end up breaking already working projects because some randome dependency introduced an unexpected change in behavior.
Is it possible to release on GitHub through the command line with an attached file that is not pushed to a repository?
I have a file over 1GB that I easily attached through a web GitHub release page, but I want to automate that using bash.
You can from command-line, using gh: cli/cli/
create a relase
gh release create <tag> [<files>...] [flags]
upload a file to that release
gh release upload <tag> <files>... [flags]
And since Github CLI 2.4.0 (Dec. 2021), you have:
the non-interactive flag --generate-notes, which allows you to skip the editor phase.
an interactive mode to choose a tag name
There's a REST API that can be used for this purpose. It's used to upload a release asset if you know the ID for the release (which you can get by querying the release itself). You can also get the upload URL by querying the release using a GET request; that returns the upload_url attribute.
If you want an example of how to do this from the command line with curl, Git LFS has a script that it uses to do releases and upload assets which you could look at. It's a little complex, but it is reasonably comprehensive.
In addition to the gh tool and directly using the REST API (as mentioned in other answers), there are several command-line tools which let you create and manipulate GitHub releases. These are likely to be much simpler to use than directly using the REST API.
There is only one* I could identify that I could unreservedly recommend, however: github-release, which is written in Go. Binaries can be downloaded from the project's Releases page, it "dogfoods (transparently uses its own tool), and is actively maintained (as at January 2022).
Some others are:
Another Go app called github-release, released by BuildKite. However, this seems to be less actively maintained, and it doesn't transparently "dogfood" (viewing its CI results require an account with BuildKite).
For Haskell developers, there's yet another tool called github-release, created by Taylor Fausak. It seems to be actively maintained; however, no downloadable executables are provided, so you must build it yourself using a Haskell compiler and build tools.
For node.js developers, there's release-it; but as a node project, it doesn't provide executable binaries that could be invoked from Bash at all.
*If there are others that I've missed, feel free to add them in comments.
I have a repository/program that requires Electron. GitHub doesn't allow adding files larger than 100MB, however, the electron.exe file in the Electron node module is 105MB so I can't figure out how to add it into my repo. Any ideas?
I think that is not required. Because Git is needed for management source code. Electron.exe and node modules can be processed by package.json.
So if you add package.json includes electron and other information, you can use easily later.
How can one depend directly on a package from a github repo? (Assuming the project has no baseline, or there is a reason not use the baseline.)
I've tried the following spec
spec
package: 'Magritte-XMLBinding'
with: [ spec
repository: 'github://magritte-metamodel/XML-Bindings:master/repository' ].
However it failed (Could not resolve: Magritte-XMLBinding [Magritte-XMLBinding.package]), and in Monticello browser under the repo I see only Magritte-Tests-XMLBinding.
What is more, when I look at the unpacked repo (in github-cache/), only the Magritte-Tests-XMLBinding has been unzipped.
The unpacked Tests package is the first in alphabetical order, which makes me feel like Metacello spec just grabs the first package without thinking.
When using git (and github), you cannot depend on packages but in complete projects. You can, however, depend on a project but load just one package of that project.
normally this definition should work:
spec
baseline: 'XMLBindings'
with: [
spec
repository: 'github://magritte-metamodel/XML-Bindings:master/repository';
loads: #('Magritte-XMLBinding') ].
However, while this answer is correct in general, in this case it will not work because the author of the project didn't included any baseline definition that would allow this kind of dependency definition to work, which suggests me he just uses that project as a mirror of the real one... so here you have three possible solutions:
send a pull request to author with a baseline
contact the project author and ask to add a baseline
use the original source instead the github mirror
I created a very simple plugin for yii2 and added it to Github.
https://github.com/harlangray/languageswitcher
When I add "harlangray/languageswitcher": "*" to the require section and run composer update on my project, it gives me an error.
Problem 1
- The requested package xxxxx could not be found in any version, there may be a typo in the package name.
Potential causes:
- A typo in the package name
- The package is not available in a stable-enough version according to your minimum-stability setting
see https:xxxxx for more details.
Read http:yyyyy for further common problems.
I am really new to github and composer. Can someone give me the steps to create a plugin and make it uninstallable via composer?
Thank you
Composer has no idea about github packages, unless you add them as under the repositories as a package.
If you want to be able to install it via the require section you'll need to add your package to Packagist. This is the site composers gets the package meta information from.
Only thing you have to do is register, click the big "Submit Package" button and point it to your github project. Optionally (but advised) you could setup a hook in github to update packagist every time you commit something to github so that you don't have to do it manually.