I'm trying to build a cli app to show a list of dart versions and allow the user to select the one to install and then switch between them.
Note: there is a flutter tool (fvm) that can switch between flutter versions (and the embedded dart tools) but this tool is specifically for dart and needs versions as well as channels.
The fvm tool uses the following endpoint:
https://storage.googleapis.com/flutter_infra/releases/releases_linux.json
But I can't find an equivalent.
Is there any method of obtaining a list of versions for each of the dart channels.
I've found:
https://storage.googleapis.com/dart-archive/channels
but you need to know the full url as I can't find any endpoints that provide a list.
I'm hoping to avoid screen scraping.
You can see how the Dart Archive Page retrieves all the information and use their endpoints:
The endpoints returns in a format such as:
{
"kind": "storage#objects",
"prefixes": [
"channels/<stable|beta|dev>/release/1.11.0/",
...,
"channels/<stable|beta|dev>/release/2.9.3/",
"channels/<stable|beta|dev>/release/29803/", // You might need to filter out results such as this
...,
"channels/<stable|beta|dev>/release/latest/"
]
}
Note: The results are not ordered in any way
Url:
https://www.googleapis.com/storage/v1/b/dart-archive/o?delimiter=%2F&prefix=channels%2F<stable|beta|dev>%2Frelease%2F&alt=json
Replace <stable|beta|dev> with which version do you want the info of.
If you need to collect info about a version you can use:
https://storage.googleapis.com/dart-archive/channels/<stable|beta|dev>/release/< VERSION NUMBER | latest>/VERSION
which will return a json object like :
{
"date": "2020-11-11",
"version": "2.10.4",
"revision": "7c148d029de32590a8d0d332bf807d25929f080e"
}
The tags for the github archive for the SDK (https://github.com/dart-lang/sdk/tags) appear to have the releases tagged reasonably usefully. The downside is that it is weighing in at 1.3GB, and there's no easy way to get a workable shallow clone of that.
Related
I have something like this in a BUILD file. I am un/commenting lines based on the operating system. Is there a graceful way to do this?
# Ubuntu
#shared_libraries = [
# "libboost_atomic.so"
#],
# OSX
shared_libraries = [
"libboost_atomic.dylib"
],
I haven't tried this however the bazel-build/rules_nodejs uses this kind of approach by wrapping the native binary and querying its's Node JS OS API.
OS Name Function(uses context given from user running node.exe)
UPDATE
Check here
Setting up a C++ Toolchain
This seems to be what you need.
I want to list all available plugins names and their short names using command line option, so that I could automate required plugin installation through jenkins command line.
Kindly advise. Thanks
So far I tried to find answer on same however I got answer only for how to list installed plugins, not for all available plugins.
I've found this link http://updates.jenkins-ci.org/download/plugins/ which lists all plugins but with their short names only
You were so close! The LAYOUT is detailed here. The information is nearby for you to parse, hopefully I got it right.
http://updates.jenkins-ci.org/download/plugins/ is indeed the location of the plugins, with the actual plugin versions sitting inside each folder.
https://updates.jenkins.io/ is the root level. You will find the list of all plugins and details at plugin-versions.json.
update-center.js, update-center.json, and update-center.json.html contain actual update center metadata in JSON, JSONP, and HTML format respectively. You can parse the json to pull everything you are looking for. There are also lists for the documentation url and the release history, as well as the updates.
This is where it's nuanced; there's stable (ie:LTS) or latest (ie:weekly) and major releases of each. Each one has its own sublist, depending on minimum version and compatibility.
Plugin Selection
Since none of this tells you what the plugins actually do, the best thing is to choose your plugins at https://plugins.jenkins.io/. Clicking on any plugin (eg: mailer) reveals a header block with details:
Mailer 1.23
Minimum Jenkins requirement: 1.642.3
ID: mailer
The ID is the short name you are looking for. Go through and find the plugins you want to use and that's your list. Don't worry about the dependencies.
About Plugin Management
Even on a standalone instance, I use a modified script of Docker install_plugins.sh to generate the full list of plugins to install .
Update 2021: As part of GSOC 2019 and refined in GSOC 2020, a new and quite functional Plugin Installation Manager CLI Tool has been introduced to replace all non-GUI plugin mgmt tools, including inatall_plugins.sh. Achieves similar results.
You can examine the outputs or use the groovy script that follows to simplify your "must have" list. Also, as dependency updates happen all the time, I also generate a list of actual installed updates if I need to reapply identically to a different instance rather than from my curated list. My curated list is ~45 plugins, with over 115 getting installed.
eg: workflow-api includes [workflow-scm-step] which includes [git, subversion], so no need to specify git. But you want to know which version you got. Occasionally you may need to explicitly add a dependency to get the latest to avoid a defect, per JENKINS-54018, plugins which were split from Jenkins.
println "Jenkins Instance : " + Jenkins.getInstance().getComputer('').getHostName() + " - " + Jenkins.getInstance().getRootUrl()
println "Installed Plugins: "
println "=================="
Jenkins.instance.pluginManager.plugins.sort(false) { a, b -> a.getShortName().toLowerCase() <=> b.getShortName().toLowerCase()}.each { plugin ->
println "${plugin.getShortName()}:${plugin.getVersion()} | ${plugin.getDisplayName()} "
}
println""
println "Plugins Dependency tree (...: dependencies; +++: dependants) :"
println "======================="
Jenkins.instance.pluginManager.plugins.sort(false) { a, b -> a.getShortName().toLowerCase() <=> b.getShortName().toLowerCase()}.each { plugin ->
println "${plugin.getShortName()}:${plugin.getVersion()} | ${plugin.getDisplayName()} "
println "+++ ${plugin.getDependants()}"
println "... ${plugin.getDependencies()}"
println ''
}
return
My motivation: I'm writing an app to help with some quantified self / time tracking type things. I'd like to use electron to record information about which app I am currently using.
Is there a way to get information about other apps in Electron? Can you at least pull information about another app that currently has focus? For instance, if the user is browsing a webpage in Chrome, it would be great to know that A) they're using chrome and B) the title of the webpage they're viewing.
During my research I found this question:
Which app has the focus when a global shortcut is triggered
It looks like the author there is using the nodObjc library to get this information on OSX. In addition to any approaches others are using to solve this problem, I'm particularly curious if electron itself has any way of exposing this information without resorting to outside libraries.
In a limited way, yes, you can get some of this information using the electron's desktopCapturer.getSources() method.
This will not get every program running on the machine. This will only get whatever chromium deems to be a video capturable source. This generally equates to anything that is an active program that has a GUI window (e.g., on the task bar on windows).
desktopCapturer.getSources({
types: ['window', 'screen']
}, (error, sources) => {
if (error) throw error
for (let i = 0; i < sources.length; ++i) {
log(sources[i]);
}
});
No, Electron doesn't provide an API to obtain information about other apps. You'll need to access the native platform APIs directly to obtain that information. For example Tockler seems to do so via shell scripts, though personally I prefer accessing native APIs directly via native Node addons/modules or node-ffi-napi.
2022 answer
Andy Baird's answer is definitely the better native Electron approach though that syntax is outdated or incomplete. Here's a complete working code snippet, assumes running from the renderer using the remote module in a recent Electron version (13+):
require('#electron/remote').desktopCapturer.getSources({
types: ['window', 'screen']
}).then(sources => {
for (const thisSource of sources) {
console.log(thisSource.name);
}
});
The other answers here are for the rendering side - it might be helpful to do this in the main process:
const { desktopCapturer } = require('electron')
desktopCapturer.getSources({ types: ['window', 'screen'] }).then(async sources => {
for (const source of sources) {
console.log("Window: ", source.id, source.name);
}
})
I know with NixOS, you can simply copy over the configuration.nix file to sync your OS state including installed packages between machines.
Is it possible then, to do the same using Nix the package manager on a non-NixOS OS to sync only the installed packages?
Please note, that at least since 30.03.2017 (corresponding to 17.03 Nix/NixOS channel/release), as far as I understand the official, modern, supported and suggested solution is to use the so called overlays.
See the chapter titled "Overlays" in the nixpkgs manual for a nice guide on how to use the new approach.
As a short summary: you can put any number of files with .nix extension in $HOME/.config/nixpkgs/overlays/ directory. They will be processed in alphabetical order, and each one can modify the set of available Nix packages. Each of the files must be written as in the following pattern:
self: super:
{
boost = super.boost.override {
python = self.python3;
};
rr = super.callPackage ./pkgs/rr {
stdenv = self.stdenv_32bit;
};
}
The super set corresponds to the "old" set of packages (before the overlay was applied). If you want to refer to the old version of a package (as in boost above), or callPackage, you should reference it via super.
The self set corresponds to the eventual, "future" set of packages, representing the final result after all overlays are applied. (Note: don't be scared when sometimes using them might get rejected by Nix, as it would result in infinite recursion. Probably you should rather just use super in those cases instead.)
Note: with the above changes, the solution I mention below in the original answer seems "deprecated" now — I believe it should still work as of April 2017, but I have no idea for how long. It appears marked as "obsolete" in the nixpkgs repository.
Old answer, before 17.03:
Assuming you want to synchronize apps per-user (as non-NixOS Nix keeps apps visible on per-user basis, not system-wide, as far as I know), it is possible to do it declaratively. It's just not well advertised in the manual — though it seems quite popular among long-time Nixers!
You must create a text file at: $HOME/.nixpkgs/config.nix — e.g.:
$ mkdir -p ~/.nixpkgs
$ $EDITOR ~/.nixpkgs/config.nix
then enter the following contents:
{
packageOverrides = defaultPkgs: with defaultPkgs; {
home = with pkgs; buildEnv {
name = "home";
paths = [
nethack mc pstree #...your favourite pkgs here...
];
};
};
}
Then you should be able to install all listed packages with:
$ nix-env -i home
or:
$ nix-env -iA nixos.home # *much* faster than above
In paths you can put stuff in a similar way like in /etc/nixos/configuration.nix on NixOS. Also, home is actually a "fake package" here. You can add more custom package definitions beside it, and then include them your "paths".
(Side note: I'm hoping to write a blog post with what I learned on how exactly this works, and also showing how to extend it with more customizations. I'll try to remember to link it here if I succeed.)
For data mining reasons, I want to get build numbers range of a jenkins job that were built on a particular day. Is there a plugin that accomplishes this or any other possible way?
Thanks,
Nick
The built-in REST JSON API will give you a list of the builds for a particular job: http://jenkins:8080/job/JOB_NAME/api/json?tree=builds[fullDisplayName,id,number,timestamp]&pretty=true
Produces something like:
{
"builds" : [
{
"fullDisplayName" : "JOB_NAME #113",
"id" : "2014-10-31_23-05-20",
"number" : 113,
"timestamp" : 1414821920808
},
{
"fullDisplayName" : "JOB_NAME #112",
"id" : "2014-10-31_17-26-39",
"number" : 112,
"timestamp" : 1414801599000
},
....
If your build ids are the basic date-stamp (as above), you can do a little string processing to filter the results. Otherwise, you can convert the timestamp to the appropriate date and filter on that.
Most Jenkins pages have a REST API link at the bottom that provides more documentation, though you often need to experiment with the API to figure out what details it can provide.
Update: As #Nick discovered, the builds result is limited to the latest 100 elements by default. According to this Jenkins issue, you can use the hidden allBuilds element to retrieve "all builds". So if you need all builds, use: http://jenkins:8080/job/JOB_NAME/api/json?tree=allBuilds[fullDisplayName,id,number,timestamp]&pretty=true
Jenkins 1.568 also introduced pagination in the API results, so it's possible to retrieve results by range. The Jenkins REST API link describes the syntax if your Jenkins version supports it.
There is the Global Stats Plugin
Which also has a JSON REST API