I have a repository that utilizes electron-updater for auto update. The weird thing is, it has no any code whatsoever pointing where the release updates are stored (I store it in GitHub releases), but somehow the autoUpdater.checkForUpdatesAndNotify() still works. There is github remote origin but I doubt it's being used by electron-updater to find the repository. I don't use any GitHub token either.
The way I release update:
Increase the version in package.json
Run electron-builder, producing .AppImage
Create new release draft in my repository's GitHub releases
Upload the .AppImage file to the draft's assets and modify the draft's tag
Download the previous release, and then open it
Voila! The update works. But how?
It's worth mentioning that if latest-linux.yml is missing from the latest release's asset, it will throw 404 error and refuse to update despite knowing the latest version's tag.
Here's the repository I'm talking about: https://github.com/SnekNOTSnake/fresh-update/releases
Also, is this how normal people release their electron app? I tried the electron-builder --publish way, but it's troublesome compared to the manual steps above.
Thanks to Caramiriel in the comment section above for the enlightenment.
How electron-updater knows where to find the repository is from resources/app-update.yml inside the produced .AppImage file.
The app-update.yml file is produced by electron-builder using the information from git remote get-url origin (if available).
I proved it by changing the origin's url to https://github.com/SnekNOTSnake/tofu-tracker.git and build the AppImage, and (surprisingly enough) the repo's value became tofu-tracker.
Related
I was trying to hide my credentials before pushing the repository publicly, as I should.
For that, I've used this resource, which worked perfectly on development mode.
For short, I've assigned global variables inside a ".api_keys.rb" file, called them on the appropriate file (devise.rb on this case) and added it to .gitignore.
Then I pushed it to GitHub. Later on, I needed to clone this one last commit. But then when I try running it, it responds with "cannot load such file -- /path/.api_keys.rb".
What am I missing? I can provide any more details if needed. Thank you.
Adding a file to .gitignore means that the file is removed from the repository and only exists locally because the file is ignored by git completely.
Because it is not stored in your git repository anymore it is not available to remote servers or other developers when pulling the repository from GitHub.
To fix this your need to remove the file from .gitignore and push it again when it still exists on your machine or you need to recreate it.
Btw the way to store, for example, API keys securely in Rails is to use encrypted files. I suggested reading in the [Rails Guides about Environmental Security and Custom Credentials].(https://edgeguides.rubyonrails.org/security.html#environmental-security)
I'm trying to switch over my current setup for Neovim (using Vim Plug) to Packer and I'm having trouble.
My Neovim is loaded from ~/.config/nvim/init.lua which sources all of my plugin and other settings. They live mostly inside of a ~/lua folder (the "main Imports") section of my configuration, including my actual plug-plugins.lua file that references all of my plugins.
-- Main Imports
require("settings")
require("colors")
require("mappings")
require("functions")
require("autocommands")
require("plug-plugins")
...
Later in the same init.lua file, I'm sourcing plugin specific settings for all of these plugins. In order to get my directory working currently, I'm installing everything with :PlugInstall and it works fine.
...
-- Plugin-specific settings
require("plugin-settings/fzf")
require("plugin-settings/fugitive")
require("plugin-settings/ultisnips")
require("plugin-settings/coc")
require("plugin-settings/treesitter")
require("plugin-settings/miscellaneous")
require("plugin-settings/toggle-terminal")
Installing Packer
The installation steps for Packer are pretty sparse, and merely state that you should clone the repository to somewhere in your "packpath" but I'm not really clear what that means. When I'm inside Neovim, and I press :set packpath? I get the following paths:
packpath=~/.config/nvim,/etc/xdg/nvim,~/.local/share/nvim/site,/usr/local/share/nvim/site,/usr/share/nvim/site,/usr/local/Cellar/neovim/HEAD-b74916c_1/share/nvim/runtime,/usr/local/Cel
lar/neovim/HEAD-b74916c_1/lib/nvim,/usr/share/nvim/site/after,/usr/local/share/nvim/site/after,~/.local/share/nvim/site/after,/etc/xdg/nvim/after,~/.config/nvim/after
This makes me think that I'm able to just clone the respository to ~/.config/nvim which is the first path listed. I'm not really sure what to do next though, or if this is even right.
Can anyone help? What are the basic steps to getting Packer installed (I'm on MacOS 11.6).
i did recently moved from vim-plug to packer, as per docs when you do git clone of the repo the path provided in readme for installation is ~/.local/share/nvim/site/pack/packer.After successful clone you can start using packer in your plugins.lua as below.
return require('packer').startup(function()
use 'wbthomason/packer.nvim'
end)
you can check the installation by running :PackerSync this will fetch (git clone) the plugin in to the packerpath which is ~/.local/share/nvim/site/pack/packer
Hope this is what you looking for?
I had the exact same situation and it turned out to just be a naming conflict. I had named my local nvim config file lua/packer.lua and changing that fixed the issue.
I'm trying to add a new package to my project with go modules. This package is using github.com/docker/docker/client and works fine outside of the project. When I run go mod vendor it pulls docker client package of version v1.13.1 which does not have some of the methods I am using in my code, but in go modules it is tagged as latest. How do I make go mod use the truly latest version of a package?
Go Wiki: Modules:
When needed, more specific versions of dependencies can be chosen with commands such as go get foo#v1.2.3, go get foo#master, go get foo#e3702bed2, or by editing go.mod directly.
If you need the latest commit on the master branch, use
go get github.com/docker/docker/client#master
This was driving me insane, too: Downloading the "master" or "latest" tag would often download versions one or two commits before HEAD. I found the answer here:
The go command defaults to downloading modules from the public Go
module mirror at proxy.golang.org. It also defaults to validating
downloaded modules, regardless of source, against the public Go
checksum database at sum.golang.org. These defaults work well for
publicly available source code.
And apparently there is some caching going on; if you wait a while it usually starts to work, alternatively it helps to temporarily set the version to a specific commit.
To fix it, I set GOPRIVATE=github.com/myuser.
In order to get the latest un-tagged version, you need to specify the commit tag you want to have when doing go get
go get github.com/docker/docker/client#[commit-hash]
Would recommend using a specific version (preferred tagged version, if not latest pseudo version instead of master). Having dependency versions locked down in the go.mod file ensures repeatability.
The latest version available in one of the go proxies is https://search.gocenter.io/github.com~2Fdocker~2Fdocker/info?version=v1.14.0-0.20190511020111-3998dffb806f
Spent the last 20 hours trying to fix a similar problem, in my case, the following steps solved the problem:
delete $GOPATH/pkg/sumdb
delete the go.mod and go.sum files
recreate the module: go mod init name
go test ./...
My circumstances don't align perfectly with the original question, but I feel it may be worth mentioning to help others in situations similar to mine:
Context
Was working with private modules, i.e., a Go module hosted from private git repository.
Access to the private repo was not an issue.
Would make and push changes to the private module.
A program that imported the private module would consistently pull an old version when running go get, even after running:
go clean -modcache
rm go.sum
go get
go mod tidy
Root Cause: I'm an Idiot
I had forgotten that Go uses VCS tagging with versioning.
Failed to update the tag to match the current commit.
The Fix
The version wasn't ready to be bumped (learning, here), so, in the private module, I ran the following command to align the version with the current commit:
Note: This assumes that all repo content has been staged/committed/pushed.
In the private module repo
git tag -d v0.0.0
git push --delete v0.0.0
git tag v0.0.0
git push origin v0.0.0
In the repo that was importing the private repo
go clean -modcache
rm go.sum
go get
go mod tidy
How do i know that online reindexing is done ?
I had a repository with name datadelivery-feed-tcp-c++ which I moved to datadelivery-feed-tcp-cpp and deleted the datadelivery-feed-tcp-c++ repository.
But On kicking online reindexing it gives a lot of below warning.It is stuck at this warning.
[2017-09-28 07:00:27,300] [Index-Batch-3] WARN com.google.gerrit.server.index.change.StalenessChecker : error checking staleness of 8737 in datadelivery-feed-tcp-c%252B%252B
org.eclipse.jgit.errors.RepositoryNotFoundException: repository not found: Invalid name: datadelivery-feed-tcp-c%252B%252B
I have tried flushing cache also
ssh -p 29418 host gerrit flush-caches --all
How do I resolve it ?
EDIT : By renaming a repo I meant, I have cloned it and imported all the data into other project, verified it and then removed it using delete project plugin
I think you already had changes in the datadelivery-feed-tcp-c++ repository and you just renamed it at the filesystem, correct? You can't do that because you need to adjust the database data accordingly. The better way to rename a repository is doing the following:
1) Clone the original repository (with all existing changes) creating a new one with the new name. Use the importer plugin to do that.
2) Remove the original repository (and all related changes). Use the delete-project plugin to do that.
Notes:
i) In your current case, first rename the repository back to the original name at the filesystem.
ii) You can download the plugins here.
I use electron-builder to build my app and succeed to build the first version which contains three outputs: foosetup.exe, foo-0.0.1-full.nupkg and RELEASES.Now I want to implement the auto-update and I have deployed a back-end service by using electron-release-server.
The auto-update need to set a feedURL which will be used to fetch updates,but the problem is that I don't know what the updates exactly means?Is it the foo-0.0.1-full.nupkg or the foo-0.0.1-delta.nupkg or another file?
The second problem is that I don't know how to create the delta file.I can just find an option remoteReleases in electron-builder which is a URL to your existing updates.If given,these will be downloaded to create delta file.But what's the URL exactly means?I find a example i which "remoteRelease": "https://github.com/user/repo"，and it creates some releases and uploads many extra files for each release such as foosetup.exe, foo-xx-full-nupkg, RELEASES.I guess electron-builder will fetch the ${remoteReleases/release/download/some-version/xxx} to download file and then diff the two file to create delta file,but I can't upload RELEASES when I create release on github,it reports that they don't support this file type.
Is there anyone can help?There're to few docs to follow for a beginer
For electron-release-server please take a look at the docs.
The delta-file will be create automatically if you use electron-builder. But in order for this to work remoteReleases must be set to a valid (and reachable) URL plus there must at least an empty file called RELEASES. So for the very first build just create an empty file and call it RELEASES.
On every future build there will be a RELEASES file created for you. Threw all the generated files in your release server (overwrite existing RELEASES) and it'll be fine.
Attention: For electron-release-server you do not need the RELEASES generated by electron-builder. electron-release-server will create one by itself.
To get started with auto-updates I'd recommend that you set up a dead-simple release-server locally. I. e.:
Create a directory and throw an empty file RELEASES in there.
Then start a simple webserver pointing at that directory (e. g. cd into/your/dir && php -S 0.0.0.0:80).
Edit your package.json: "remoteRelease": "http://localhost"
Then build your installer: npm run dist
It should successfully build and you should see some GET requests on your local server.
Take the generated files and stuff them into the directory you created.
Now increment your version and start another build: npm run dist
You should see some GET requests again and there should be an addition delta-file being created.
Again stuff all those things into the directory (or for electron-release-server upload the assets .nupkg, .exe and delta into a new release).
Hope that helps. Feel free to comment if something is unclear.
Check out this sample app that I have created https://github.com/electron-delta/electron-sample-app
It uses two npm packages.
#electron-delta/builder
#electron-delta/updater
More details https://github.com/electron-delta/electron-delta#installation