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.
Related
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.
I would like to list all NPM packages available in a repository on GitHub and use code parsing to get just needed information of the packages using PowerShell.
How do I identify these packages?. if they are in packages.json file, there seems to be many of the "packages.json" file name in some repos.
You can see multiple package.json files are part of nested dependencies, as seen here.
If you somehow had to see those dependencies (direct and indirect) as one package.json, that is what json-merge or package-merge are for.
Yocto has a set of independent repositories containing the base system (Poky) and various software components (all the meta-* repositories here, and also openembedded layer index). So when you want to build an image for specific device and purpose, you need a handful of repositories checked out.
These are all tied together by the conf/bblayers.conf and conf/local.conf files in the build directory. But that is a build directory—it is supposed to be disposable, containing only information that can be easily regenerated on request. And it does—except for the list of layers in conf/bblayers.conf and a couple of definitions like the MACHINE in the conf/local.conf that define the target system to build for.
How should I version this information?
Currently we have a rather hacky script that assembles the build directory and writes the config files, but it does not know how to properly update them when it changes.
So is there a better option? Preferably one that would avoid any additional steps between checkout/update (with submodules or repo), oe-init-build-env init script (which creates the build directory if it does not exist) and running bitbake with appropriate target image?
Actually, repo is a convenient tool for managing manifest files with all the needed repositories.
Then you can use TEMPLATECONF to version local.conf and bblayers.conf. Here is how we do it: https://pelux.io/software-factory/master/chapters/baseplatform/building-PELUX-sources.html
The Poky distribution itself uses the Combo Layer tool, which seems to be designed to address this particular problem. However, it's not very clear what the workflow is supposed to look like, when using this tool.
Regarding the default bblayers.conf and local.conf files, you can either version them anywhere in your project and have a script copy them in your build folder after calling oe-init-build-env, or simmply use meta-poky/conf/bblayers.conf.sample and meta-poky/conf/local.conf.sample, which are automatically installed by oe-init-build-env when first creating the build directory.
Now, when you make changes or add layers, you will have to clear the build directory for the changes in the .sample files to take effect.
I was looking into the VSCode build process and it looks like the mixinProduct function from gulp.vscode.js was removed. I saw a mention to a distro repo and was curious how you all build and release VSCode now. In the past you would pull in product.json in gulp.vscode.js by the use of an environment variable PRODUCT_JSON_FILE.
It looks like things have been moved into a private repo for a gulp task called mixin that pulls in product.json config files for different qualities and different releases types. If you could shed some light into how this works that would be awesome.
Also what are you using for the CI engine to build the insider releases?
The specifics of how VS Code handles release are not public.
At a high level, the released "VS Code Build" is exactly the same code as from the public github repo, just with a few different assets and configuration files included. This comment provides a bit more detail
NuGet is just great addition for Visual Studio. And it also allows for custom NuGet repositories as long as you provide custom URLs to them.
For company-related projects we can have own NuGet repositories serving whatever libraries are needed for internal projects. The main problem is that each developer has to configure this manually within Visual Studio.
Question
Is it possible to set these URLs by domain security policy settings? This would be great, because every new team member that would install Visual Studio would automatically get these URLs and gettig project source code could automatically load related libraries (with the new NuGet feature that loads missing ones on build).
So #Haacked and Steve Sanderson... Is this possible?
NuGet 2.1 introduced hierarchical configuration settings for NuGet. This allows you to specify things like additional repositories at a project/solution level rather than having to have everyone receive the settings through a group policy.
Release notes: http://docs.nuget.org/docs/release-notes/nuget-2.1
By setting a NuGet repository at the solution level, everyone working on the solution will get the additional repository added to their package sources.
That is not yet possible. I'm pretty sure there's a feature request already for this in http://nuget.codeplex.com/. I recommend finding that feature and commenting on it. If you can't find it, start a discussion. :)