Simple collection of Groovy scripts to help me maintain some Jenkins systems.
See also https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+Script+Console
Please comment & let me know if you have a fork / fixes you'd like to include.
Simple collection of Groovy scripts to help me maintain some Jenkins systems.
See also https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+Script+Console
Please comment & let me know if you have a fork / fixes you'd like to include.
| /* | |
| OUTLINE FOR AN APP BUILT WITH RXJS AND REACT, USING AN ELASTICSEARCH FACETED SEARCH | |
| MODULE AS AN EXAMPLE, READ FROM BOTTOM UP IF YOU WANT TO GO OUTSIDE IN, START FROM | |
| TOP TO SEE HOW THE SEARCH MODULE IS COMPOSED. | |
| If you find this I would love to hear some feedback - it's not designed to work without | |
| any modification though, it's just supposed to outline the architecture off-the-top-of- | |
| my-head-pretty-close-to-working psuedocode of something that you might actually need to | |
| build to drive out if the pattern is any good! | |
| */ |
nix-channel and ~/.nix-defexpr are gone. We'll use $NIX_PATH (or user environment specific overrides configured via nix set-path) to look up packages. Since $NIX_PATH supports URLs nowadays, this removes the need for channels: you can just set $NIX_PATH to e.g. https://nixos.org/channels/nixos-15.09/nixexprs.tar.xz and stay up to date automatically.
By default, packages are selected by attribute name, rather than the name attribute. Thus nix install hello is basically equivalent to nix-env -iA hello. The attribute name is recorded in the user environment manifest and used in upgrades. Thus (at least by default) hello won't be upgraded to helloVariant.
@vcunat suggested making this an arbitrary Nix expression rather than an attrpath, e.g. firefox.override { enableFoo = true; }. However, such an expression would not have a key in the user environment, unlike an attrpath. Better to require an explicit flag for this.
TBD: How to deal with search path clashes.
Automatically retries until all three checks are solved
It starts out with:
const initialState = {
checks: {
one: undefined,
two: undefined,
three: undefined| #!/usr/bin/awk -f | |
| # This program is a copy of guff, a plot device. https://github.com/silentbicycle/guff | |
| # My copy here is written in awk instead of C, has no compelling benefit. | |
| # Public domain. @thingskatedid | |
| # Run as awk -v x=xyz ... or env variables for stuff? | |
| # Assumptions: the data is evenly spaced along the x-axis | |
| # TODO: moving average |
Following is my mental journey and interaction with ocaml tooling as a newb. It's not meant as a negative criticism, but a form of constructive feedback. Part of the confusion may be caused by my own skill issues. Hopefully this serves as a case study of areas that could be streamlined or better documented.
So it appears I can make an ocaml/reason project with npm. Great! It's kind confusing. Dependencies are not really npm dependencies, but are in the package.json? Npm install doesn't work with them inside? Ah. It kinda just executes esy via npm, which runs opam under the hood? Maybe I'll try the "native" way with opam/dune directly...
| src_dir ?= src | |
| build_dir ?= build/ | |
| main ?= main | |
| mode ?= debug | |
| arch ?= $(shell uname -m) | |
| os ?= $(shell uname -s | tr '[:upper:]' '[:lower:]') | |
| ifeq ($(os), linux) | |
| abi = musl |
| src_dir ?= src | |
| build_dir ?= build/ | |
| main ?= main | |
| mode ?= debug | |
| arch ?= $(shell uname -m) | |
| os ?= $(shell uname -s | tr '[:upper:]' '[:lower:]') | |
| ifeq ($(os), linux) | |
| abi = musl |