text:
> The project was stopped maintaince, please move your focus to brand new React Redux Boilerplate:
>
> https://github.com/xuqingkuang/react-redux-boilerplate

# React Reflux Boilerplate

Another template that makes react and reflux web app developmet easier.

## Demo

[Click here for demo](http://xuqingkuang.github.io/react-reflux-boilerplate)

## Features

* React 0.14
* React Router 1.0.0
* Reflux 0.3.0 ( Refactor of Flux )
* Node 5.0 Compatible
* Babel 6.1.x for ES7 support
* Browser Live Reload based on [react-transform-hmr](https://github.com/gaearon/react-transform-hmr), it build codes pretty fast!
* CSS / HTML / JS minification / Image optimization when built
* JS code duplication removal during built
* Code is minimized and pure write with Javascript ES7, focused on core features only.

If you are interested, please read the `package.json` file for all installed modules.

Feel free to contribute or fork it if you find this repo could help the community.

## TODO

* Testing framework for React - [Jest](https://github.com/facebook/jest)
* A resposive solution with [Radium](http://projects.formidablelabs.com/radium/)
  or [react-responsive](https://github.com/contra/react-responsive)

## Installation

### Requirements

* Node 4.0 is required for better experiences, previous versions maybe compatible
  but not tested yet.
* Gulp must be installed globally with `$ npm install -g gulp`

### Start

1. Clone the repo - `$ git clone https://github.com/xuqingkuang/react-reflux-boilerplate`
2. Install the requirements - `$ cd react-reflux-boilerplate && npm install`

### Commands / Gulp Tasks

#### Start develop environment

```$ gulp```

Run gulp directly without any options will build the codes and start a
development web server on `http://localhost:8000`, then you can open a browsre to
access the page, the codes in `src/` will be compiled at run time when change
anything, and the browser will auto reload.

By the way, the step is running on memory, there's no any files generated.

#### Build the codes for production

```$ gulp production```

The codes will be compiled and placed to `public/` folder, all of them are
minimized.

####  Clean the built folder

```$ gulp clean```

The all files in `public` folder will be removed.

### Structure

1. `src/`       - all of sources
2. `assets/`    - all of static files
3. `public/`    - built minimized codes, for production environment.

__Note__ : `assets/` and `src/` will be compiled into `public/` folder when you
run `gulp production` command.

## Known Issues

### Build interrupted by react-router babel issue

Because of react-router didn't support Babel 6 yet, it's need to update the
`node_modules/react-router/.babelrc` file manually by following contents.

```{
  "presets": ["babel-preset-stage-0"]
}
```

and install `babel-preset-stage-0` by command  `$ npm install babel-preset-stage-0`
for temporary solution for building broken.

But I think the step will could be ignore after next react-router released.

repository: xuqingkuang/react-reflux-boilerplate

repo_name: xuqingkuang/react-reflux-boilerplate


text:
---
title: What is Broccoli.js?
---

Broccoli is a JavaScript build tool. A build tool is a piece of software that is responsible for assembling your
applications assets (JavaScript, CSS, images, etc) into some distributable form, usually to run in a browser.
All configuration is done in JavaScript (no confusing/messy config files) via a modular plugin architecture.

${toc}

## What is a build tool?

A build tool's job is to take input files (your JavaScript, CSS, HTML, etc), to process them and output the result
of those transformations, usually into some distributable form. Typically this will involve things like JavaScript
transformations to allow you to write newer syntax that will work in a browser, to use a CSS pre-processor like
Sass for your CSS, etc.

Broccoli.js is different from other build tools. You may be used to tools like [Grunt](https://gruntjs.com/) (a
task runner), [Gulp](https://gulpjs.com/) (streams and pipes) or [Webpack](https://webpack.js.org/) (a module
bundler), these all aim to solve different problems than what Broccoli was built for.

Broccoli provides a modular plugin API to leverage other Node tools. Tools like [Babel](https://babeljs.io/),
[Rollup](https://rollupjs.org/), [Node-Sass](https://github.com/sass/node-sass),
[Webpack](https://webpack.js.org/), [Browserify](http://browserify.org/), and many more can easily be used with
Broccoli. These tools perform the actual work by transforming files, Broccoli merely connects inputs to outputs.

## Thinking in Broccoli

There are 3 main concepts to get your head around when using Broccoli:

* [Directories](#directories)
* [Plugins](#plugins)
* [Trees](#trees)

### Directories

Using the above tools in a standalone fashion is relatively straight forward, they read input files, and write
to output files. The difficulty comes when connecting different tools together as you need to manage all the
interim state yourself. The only common interface between them is the file system.

Say we want to concatenate our JavaScript files, minify them, and copy the results to our build directory:

```js
import fs from 'fs';
import path from 'path';
import minify from 'minify';
import readDir from './readDir';
import readFiles from './readFiles';

function concatFiles(sourceDir, outputFile) {
    const output = readDir(sourceDir).reduce((output, file) => output += `;${file.content}`, '');
    fs.writeFileSync(outputFile, output)
}

function minifyFiles(sourceFiles, outputDir) {
    return readFiles(sourceFiles).map(file => {
        const minified = minify(file.path);
        const outputFile = `${outputDir}/${file.name}.min.${file.extension}`;
        fs.writeFileSync(outputFile, minified)
        return outputFile;
    })
}

function copyFiles(sourceFiles, outputDir) {
    sourceFiles.forEach(filePath => {
        const file = path.basename(filePath);
        fs.createReadStream(path).pipe(fs.createWriteStream(`${outputDir}/${file}`));
    });
}

const concatted = concatFiles('app', '/tmp/concat-files')
const minified = minifyFiles(concatted, '/tmp/minified-files')
copyFiles(minified, './build');
```

The above is all well and good, but notice how we have to handle the state between each operation. Now imagine how
this scales as our build pipeline grows, adding in Sass compilation, JavaScript transpilation (Babel),
fingerprinting, etc. That's lots of temp directories and file state that you have to handle.

Broccoli works by managing a set of directories, connected together by plugins, which describe how files
are moved or transformed at each step of the build process. Broccoli ensures plugins are called in the prescribed
order, and writes the result to a `target` directory. Each plugin is responsible for processing files passed to
it in input directories, and writing files to its output directory. This allows you to focus on the
transformations and not how files are passed between each plugin.

For example:
```sh
app                                                       [target]
 ├─ src                                                    │
 │   ├─ index.js   --> ConcatPlugin() ┐                    │
 │   └─ other.js                      ├─ MergePlugin() --> ├─ prod.js
 └─ styles                            │                    └─ site.css
     ├─ site.scss  --> SassPlugin() ──┘
     └─ layout.scss
```

Broccoli itself doesn't really care about files, it simply takes source directories and passes them as inputs to
plugins, creates an output directory for the plugin to write to, and passes that output directory as an input
to the next plugin.

Broccoli is configured with a file in the root of your project called `Brocfile.js`. This file defines the build
pipeline for your application, and is written in plain old JavaScript. The order in which operations happen is
determined by this build file. All that is required is that `export default` returns a function that returns a
plugin/string.

You can think of broccoli-plugins much like a simple programming language, where the output of a function can be
passed as the input(s) to another function.

E.g.:

```js
export default options => {
    let js = babel('src');
    js = uglify(js);

    let css = sass('src/styles', 'site.scss');
    css = autoprefixer(css);

    return merge([js, css]);
};
```

This could also be expressed as:
```js
export default options => {
     return merge([
        uglify(
            babel('src')
        ),
        autoprefixer(
            sass('src/styles', 'site.scss')
        )
    ])
};
```

In the above, a `src` directory is passed to the `babel()` plugin (which will convert our new ES6 syntax into
ES5 that runs in the browser), the output of that is passed to the `uglify()` plugin which will minify our JS
into a smaller format. The output of `uglify()` will in turn be passed as 1 input to `merge()`.

Additionally, a `src/styles` directory and the input file `site.scss` is passed to `sass()` which will convert your
`.scss` files into `.css` files, its output (your css) is passed as an input to `autoprefixer()` which will add
vendor  prefixes (like `-ms` or `-webkit`) to attributes, which is then in turn passed into the `merge()` plugin.

The `merge()` plugin will copy the contents of each of its inputs into its output directory. Thus, it merges our
uglified JavaScript and out vendor prefixed css. This then becomes our final output and is what is written to
our target (destination) directory.

Finally, the `export default () => ` line exports a function that Broccoli will invoke with an `options` object,
that contains an `env` property to indicate the environment. This is set from the `--environment` CLI argument and
defaults to `development`.

This should all be fairly familiar to you if you've ever written JavaScript (or any programming language for that
matter) before; it's just inputs and output.

Note: [ES Modules](https://nodejs.org/api/esm.html) syntax is supported by Broccoli since version 2.1.0. Prior
to this, standard CommonJs syntax with `require` and `module.exports` should be used.

### Plugins

Plugins are what a build pipeline developer will interact with most. Plugins are what do the actual work of
transforming files at each step of the build process. The API of a plugin is pretty simple, all that's required is
creating a class that extends the [broccoli-plugin](https://github.com/broccolijs/broccoli-plugin) base class, and
implementing a `build()` method, that performs some work or returns a promise.

```js
import Plugin from 'broccoli-plugin';

class MyPlugin extends Plugin
{
  build() {
    // A plugin can receive single or multiple inputs nodes/directories
    // The files are available in this.inputPaths[0]/this.inputPaths[1]...
    // You can do anything with these files that you can do in Node
    // The output of your plugin must write to this.outputPath
  }
}
```

A broccoli-plugin has only one purpose, to transform the files from its `this.inputPaths` directories to its
`this.outputPath` directory when its `build()` function is invoked. Anything you can do in Node, you can do in
the `build()` method. A plugin can receive one or multiple inputs, and these are available in the `this.inputPaths`
array in the order they are provided.

`this.inputPaths` contains paths to directories, that are the `outputPath` of previous plugins. Each `inputPath`
contains files that you can manipulate and write to `this.outputPath`. Broccoli will handle the state of these
directories and take responsibility for passing them between plugins.

There is a special case where a `string` is passed as an input to a plugin. When parsing your build pipeline,
Broccoli will automatically convert a string input into a
[source plugin](https://github.com/broccolijs/broccoli-source). This plugin basically connects its input directory
to its output directory, and also allows Broccoli to `watch` and be notified when files within the input
directory change and trigger a rebuild. You can also manually create an `unwatched` directory from a string by
using [UnwatchedDir](https://github.com/broccolijs/broccoli-source#new-unwatcheddirdirectorypath-options),
changes in this directory will not trigger a rebuild.

### Trees

The build pipeline is a series of connected plugins, from one or more input directories to a single target directory.
Working from the target directory (the final output) back up to the source directories resembles a tree. Think of a
piece of Broccoli and you should have a mental model of what a build pipeline looks like.

<div style="text-align: center">

![broccoli tree](/assets/logo/logo-small.png)

</div>

Broccoli parses the result of the `export default` from the `Brocfile.js`, and traverses up all of the connected
nodes all the way to the source directories to produce this tree.

As Broccoli does this, it sets up the filesystem state for each plugin, creating an `outputPath` for each to write
to. Broccoli normalizes each plugin into what it calls `nodes`, that contain information about the inputs and
output of each item in the build pipeline.

You may often encounter the term "tree" when reading plugin READMEs or in tutorials, just remember a tree is a
connected set of plugins.

## Building

When Broccoli starts up, the build file `Brocfile.js` file in the root of the project is parsed, from last
(target) plugin/node up to the source directories. As it does so, Broccoli handles wiring up all of the nodes'
inputs and outputs into a graph (from the end node up to the start nodes), creating temporary output directories
for each as it goes, linking inputs to outputs.

This graph of nodes is held in memory, and reused whenever a rebuild is triggered. When a `build` or `rebuild`
is triggered, Broccoli will invoke the `build()` method on each plugin in the order they're defined in the
`Brocfile.js`, building one plugin at a time, and finally write the files from the final node into the
destination build directory.

Here's an example:

```js
import mergeTrees from "broccoli-merge-trees"; // broccoli merge-trees plugin
export default () => mergeTrees(["dir1", "dir2"]);
```

This is a very simple `Brocfile.js` that merely merges the contents of `dir1` and `dir2` into the output
directory. The node graph would be represented as follows:

```
source plugin
               =====> merge plugin
source plugin
------------------------
/dir1 => source node 1
/dir2 => source node 2
mergeTrees(
    'dir1', => source node, implicitly created when using a string as an input
    'dir2' => source node, implicitly created when using a string as an input
)
export default () => broccoli-merge-trees node with source nodes dir1 and dir2 as inputs
```

The two input nodes reference two source directories, `dir1` and `dir2`.
Thus `export default` contains a node that references the two input nodes, and an output path that will contain the
contents of `dir1` and `dir2` when the `build` command is run.

## Serving

One last thing. Broccoli comes with a built in development server that provides an HTTP server to host your assets
in development, and perform rebuilds when source directories (nodes) change.

The local HTTP server runs on `http://localhost:4200`

Ok, that pretty much wraps up the basics, let's continue on and learn how to setup a Broccoli build pipeline in the
[Getting Started](/getting-started.html) guide.

license: MIT

branch_name: refs/heads/code

extension: md

gha_license_id: MIT

license_type: permissive


text:
[TOC]

# Overview

The I Ching (Yijing), also Classic of Changes or book of Changes, is an
ancient Chinese divination text and the oldest of the Chinese classics.
- Possessing a history of more than two and a half millennia of
  commentary and interpretation, the I Ching is an influential text read
  throughout the world, providing inspiration to the worlds of religion,
  psychoanalysis, business, literature, and art.

# References

[wiki]: https://en.wikipedia.org/wiki/I_Ching
[yijing]: https://www.biroco.com/yijing/index.htm

branch_name: refs/heads/master


text:
---
#
# Use the widgets beneath and the content will be
# inserted automagically in the webpage. To make
# this work, you have to use › layout: frontpage
#
layout: frontpage
title: "Gunharth Randolf – Specialist in Web Technologies"
header:
   image_fullwidth: "start.jpg"
widget-1:
    title: "Projects - Coming Soon ..."
    url: '#'
    text: 'An overview of open source, experiments and work related projects I am involved in.'
    image: unsplash_9-480x270.jpg
widget-2:
    title: "Blog - Coming Soon ..."
    url: '#'
    text: "Yet another blog ;-)! Diving back in into technologies lately there's some stuff that's blog-worthy.
    image: unsplash_1-480x270.jpg
widget-3:
    title: "Contact"
    url: '/contact'
    text: 'Feel free to get in touch with me by using the contact form on this site, through GitHub, LinkedIn or Twitter.'
    image: github-480x270.jpg
---


text:
![build](https://github.com/ParamagicDev/bridgetown-automation-stimulus/workflows/build/badge.svg)

# Purpose

To provide an easy way for Bridgetown users to add Stimulus to their project.

## Prerequisites

- Ruby >= 2.5
- Bridgetown >= 0.15.0

```bash
bridgetown -v
# => bridgetown 0.15.0 "Overlook"
```

This project requires the new `apply` command introduced in Bridgetown
`0.15.0`

## Usage

### New project

```bash
bridgetown new <newsite> --apply="https://github.com/ParamagicDev/bridgetown-automation-stimulus"
```

### Existing Project

```bash
[bundle exec] bridgetown apply https://github.com/ParamagicDev/bridgetown-automation-stimulus
```

## Getting Started

### Adding controllers

Controllers should be placed in the `./frontend/javascript/controllers/` directory.
Make sure the controllers follow the `[name]_controller.js` convention.
Check out more @ [stimulusjs.org](https://stimulusjs.org)

## Testing the "apply" command locally

Right now there is one big integration test which simply
checks that the files were created for Stimulus in a new bridgetown project.

In order for the tests to pass, you must first push the branch you're working on and then
wait for Github to update the raw file so the remote automation test will pass

```bash
git clone
https://github.com/ParamagicDev/bridgetown-automation-stimulus/
cd bridgetown-automation-stimulus
bundle install
bundle exec rake test
```

### Testing with Docker

```bash
git clone
https://github.com/ParamagicDev/bridgetown-automation-stimulus
cd bridgetown-automation-stimulus
docker-compose up --build
```


text:
---
id: 5488
title: Atticus Shaffer
date: 2012-04-06T20:01:44+00:00
author: chito
layout: post
guid: https://ukdataservers.com/atticus-shaffer/
permalink: /04/06/atticus-shaffer/
---

* some text
{: toc}

## Who is  Atticus Shaffer

Television actor best known to audiences as Brick Heck in ABC’s family comedy series The Middle. He is also known for providing voices for the 2012 film Frankenweenie and the Disney Junior television series The Lion Guard.

## Prior to Popularity

He was diagnosed with Osteogenesis Imperfecta, which contributes to his small frame.

## Random data

He made his film debut in the horror-thriller The Unborn.

## Family & Everyday Life of Atticus Shaffer

He was born to Ron and Debbie Shaffer.

## People Related With  Atticus Shaffer

He did voice acting with Martin Short in the 2012 Disney film Frankenweenie.

branch_name: refs/heads/main


text:
# dynamic-blocks
[![Build Status](https://travis-ci.org/dynamic/dynamic-blocks.svg?branch=master)](https://travis-ci.org/dynamic/dynamic-blocks)
[![Scrutinizer Code Quality](https://scrutinizer-ci.com/g/dynamic/dynamic-blocks/badges/quality-score.png?b=master)](https://scrutinizer-ci.com/g/dynamic/dynamic-blocks/?branch=master)
[![Code Coverage](https://scrutinizer-ci.com/g/dynamic/dynamic-blocks/badges/coverage.png?b=master)](https://scrutinizer-ci.com/g/dynamic/dynamic-blocks/?branch=master)
[![codecov](https://codecov.io/gh/dynamic/dynamic-blocks/branch/master/graph/badge.svg)](https://codecov.io/gh/dynamic/dynamic-blocks)

various blocks for the SilverStripe Blocks module

## Requirements

- SilverStripe 3.4

## Installation

This is how you install dynamic-blocks.

## Example usage

You use dynamic-blocks like this.

## Documentation

See the [docs/en](docs/en/index.md) folder.

repository: helpfulrobot/dynamic-dynamic-blocks

repo_name: helpfulrobot/dynamic-dynamic-blocks


text:
# Rivets.js

Rivets.js is a declarative data binding facility that plays well with existing frameworks such as [Backbone.js](http://backbonejs.org), [Spine.js](http://spinejs.com) and [Stapes.js](http://hay.github.com/stapes/). It aims to be lightweight (2.3KB minified and gzipped), extensible, and configurable to work with any event-driven model.

---

Rivets.js keeps your UI and model data in sync for you, so you can spend less time manually tying into the DOM and more time on your actual data and application logic.

Out-of-the-box it’s got:

- **One-way** and **two-way** binding to/from DOM elements.
- **Computed properties** with dependent attributes.
- **Formatters** to allow mutatating values through piping.
- **A powerful custom bindings API** for building your own binding routines.
- **Easy debugging** and manual bidirectional syncing of bindings.

## Getting Started and Documentation

All documentation for Rivets.js is available on the [homepage](http://rivetsjs.com). See [#configure](http://rivetsjs.com#configure) to learn how to properly configure Rivets.js for your app.

## Building and Testing

Make sure to run npm install so that you have all the development dependencies. To have the test suite run as part of the build process, you'll also need to have PhantomJS installed.

#### Building

Rivets.js uses [grunt](http://gruntjs.com/) as the build tool. Run `grunt build` from within the project root to compile + minify the source into */lib*, or just run `grunt` to have it watch the source file for changes — it will compile + minify into */lib* and run the test suite whenever the source file is saved.

#### Testing

Rivets.js uses [Jasmine](http://pivotal.github.com/jasmine/) as the testing framework. You can run the test suite with `grunt spec` or by opening */spec/index.html*.

repository: leoasis/rivets

repo_name: leoasis/rivets


text:
title: Custom meta tags
summary: How to add extra meta tag information to pages.

# Custom Meta Tags

Out the box, your site will include two fields per page for meta tags: one for the description and one for custom
tags. The custom fields are defined by entering in the HTML that you would like outputted. While this is the most
flexible system for custom meta tags, you may want to add extra specific fields for things like author, copyright,
date of publication, etc.

To do this, define the fields that you'd like specified on your page type and add the fields to the CMS view:

```php
class Publication extends Page
{
    private static $db = [
        'MetaAuthor' => 'Varchar(255)',
        'MetaCopyright' => 'Varchar(255)'
    ];

    ...

    public function getCMSFields()
    {
        $fields = parent::getCMSFields();

        $metaField = $fields->fieldByName('Root.Main.Metadata');
        $metaField->push(TextareaField::create('MetaAuthor', 'Author'));
        $metaField->push(TextareaField::create('MetaCopyright', 'Copyright'));

        return $fields;
    }

    ...
}
```

If you run `dev/build?flush=all` and then browse to your page type, you'll see the fields you just defined in the
expandable Meta Tags area on the main Page edit view.

To display them, you'll need to override the MetaTags function in your page type:

```php
class Publication extends Page
{
    ...

    public function MetaTags($includeTitle = true)
    {
        $tags = parent::MetaTags($includeTitle);

        if ($this->MetaAuthor) {
            $tags .= "<meta name=\"author\" content=\"" . Convert::raw2att($this->MetaAuthor) . "\" />\n";
        }
        if ($this->MetaCopyright) {
            $tags .= "<meta name=\"copyright\" content=\"" . Convert::raw2att($this->MetaCopyright) . "\" />\n";
        }

        return $tags;
    }
}
```

That will take all of the tags that the `Page::MetaTags()` function defines and then add our custom ones on.

We could automatically generate some of our own easily enough:

```php
class Publication extends Page
{
    ...

    public function MetaTags($includeTitle = true)
    {
        $tags = $parent->MetaTags($includeTitle);

        ...

        $tags .= "<meta name=\"last-modified\" content=\"" . date('Y-m-d@G:i:s T', strtotime($this->LastEdited)) . "\" />\n";

        return $tags;
    }
}
```

repository: silverstripe/cwp

gha_language: PHP

repo_name: silverstripe/cwp


text:
# flask-lint
[![Build Status](https://travis-ci.org/tangwz/Flask-Lint.svg?branch=master)](https://travis-ci.org/tangwz/Flask-Lint.svg?branch=master)
[![Coverage Status](https://coveralls.io/repos/github/tangwz/Flask-Lint/badge.svg?branch=master&service=github)](https://coveralls.io/github/tangwz/Flask-Lint?branch=master)

Simple integration of Flask and [jsonlint](https://github.com/tangwz/jsonlint).

# Installation
Install or upgrade using pip.

    pip install flask-lint

Install from source:

    python setup.py install

repository: tangwz/Flask-Lint

repo_name: tangwz/Flask-Lint


text:
# SKGeometry

**SKGeometry** provides several helper methods that can be used to create common geometric shapes.

## Methods

There are a few helper methods that can be used to create geometric shapes in the `SKGeometry` type:

| Method                        | Description |
| :---------------------------- | :---------- |
| **CreateSectorPath**          | Creates a path with the shape of sector/section of a doughnut/pie chart. |
| **CreatePiePath**             | Creates a path with the shape of a doughnut/pie chart. |
| **CreateSquarePath**          | Creates a path with the shape of a square. |
| **CreateRectanglePath**       | Creates a path with the shape of a rectangle. |
| **CreateTrianglePath**        | Creates a path with the shape of a triangle. |
| **CreateRegularPolygonPath**  | Creates a path with the shape of some regular polygon. |
| **CreateRegularStarPath**     | Creates a path with the shape of a square. |

## Extension Methods

Some of these shapes can also be draw directly on a `SKCanvas` using the extensions methods:

```csharp
SKCanvas canvas = ...

canvas.DrawStar(
    100, 100, // x, y
    100,      // outer radius
    50,       // inner radius
    5);       // points
```

gha_language: C#


text:
---
title: "The Scatter in Cluster Scaling Relations with a Complete Cluster Sample"
collection: talks
type: "Poster"
venue: "Snowcluster 2018"
date: 2018-03-15
location: "Salt Lake City, Utah"
---
#### Abstract
We measure the scatter in the richness-mass relation for the 30 richest clusters in the redMaPPer catalog for the Sloan Digital Sky Survey (SDSS) using gas mass measurements from the Chandra Xray Observatory. As part of our analysis, we test for the consistency of the mass calibration of the SDSS redMaPPer and Weighing the Giants mass cluster samples. Our results provide the first direct estimate of the scatter in mass of a complete sample of redMaPPer clusters.

#### Poster
[Click here to see the poster!](../../files/snowcluster_2018_poster.pdf)


text:
# react-native-micoup-image-picker

[![CI Status](https://img.shields.io/travis/kimkr/react-native-micoup-image-picker.svg?style=flat)](https://travis-ci.org/kimkr/react-native-micoup-image-picker)
[![Version](https://img.shields.io/cocoapods/v/react-native-micoup-image-picker.svg?style=flat)](https://cocoapods.org/pods/react-native-micoup-image-picker)
[![License](https://img.shields.io/cocoapods/l/react-native-micoup-image-picker.svg?style=flat)](https://cocoapods.org/pods/react-native-micoup-image-picker)
[![Platform](https://img.shields.io/cocoapods/p/react-native-micoup-image-picker.svg?style=flat)](https://cocoapods.org/pods/react-native-micoup-image-picker)

## Example

To run the example project, clone the repo, and run `pod install` from the Example directory first.

## Requirements

## Installation

react-native-micoup-image-picker is available through [CocoaPods](https://cocoapods.org). To install
it, simply add the following line to your Podfile:

```ruby
pod 'react-native-micoup-image-picker'
```

## Author

kimkr<EMAIL_ADDRESS>
## License

react-native-micoup-image-picker is available under the MIT license. See the LICENSE file for more info.

repository: kimkr/MicoupImagePick

gha_language: Objective-C

repo_name: kimkr/MicoupImagePick


text:
# Jigsaw

Jigsaw Kaggle competition

## Development

- To add a new library:
  - `pip3 install <library>`,
  - save the list of libraries: `pip3 freeze > requirements.txt`.

## Useful links

- Competition: https://www.kaggle.com/c/jigsaw-unintended-bias-in-toxicity-classification

repository: antoinewg/Jigsaw

repo_name: antoinewg/Jigsaw


text:
#### Building a reference

Starting with a genome and a genome annotation a transcriptome index can be built with `kallisto` via `kb ref`. This allows flexibility in building a transcriptomes from genomes and associated genome annotations. In addition `kb ref` can be used to download pre-built indices:

```
$ kb ref
usage: kb ref [-h] [--tmp TMP] [--keep-tmp] [--verbose] -i INDEX -g T2G -f1
              FASTA [-f2 FASTA] [-c1 T2C] [-c2 T2C] [-n N]
              [-d {human,mouse,linnarsson}] [-k K]
              [--workflow {standard,lamanno,nucleus,kite}] [--lamanno]
              [--overwrite]
              fasta gtf [feature]

Build a kallisto index and transcript-to-gene mapping

positional arguments:
  fasta                 Genomic FASTA file(s), comma-delimited
  gtf                   Reference GTF file(s), comma-delimited
  feature               [`kite` workflow only] Path to TSV containing barcodes
                        and feature names.

optional arguments:
  -h, --help            Show this help message and exit
  --tmp TMP             Override default temporary directory
  --keep-tmp            Do not delete the tmp directory
  --verbose             Print debugging information
  -n N                  Number of files to split the index into. If this
                        option is specified, the FASTA that is normally used
                        to create an index is split into `N` approximately-
                        equal parts. Each of these FASTAs are indexed
                        separately.
  -d {human,mouse,linnarsson}
                        Download a pre-built kallisto index (along with all
                        necessary files) instead of building it locally
  -k K                  Use this option to override the k-mer length of the
                        index. Usually, the k-mer length automatically
                        calculated by `kb` provides the best results.
  --workflow {standard,lamanno,nucleus,kite}
                        Type of workflow to prepare files for. Use `lamanno`
                        for RNA velocity based on La Manno et al. 2018 logic.
                        Use `nucleus` for RNA velocity on single-nucleus RNA-
                        seq reads. Use `kite` for feature barcoding. (default:
                        standard)
  --lamanno             Deprecated. Use `--workflow lamanno` instead.
  --overwrite           Overwrite existing kallisto index

required arguments:
  -i INDEX              Path to the kallisto index to be constructed. If `-n`
                        is also specified, this is the prefix for the n
                        indices to construct.
  -g T2G                Path to transcript-to-gene mapping to be generated
  -f1 FASTA             [Optional with -d] Path to the cDNA FASTA (lamanno,
                        nucleus) or mismatch FASTA (kite) to be generated

required arguments for `lamanno` and `nucleus` workflows:
  -f2 FASTA             Path to the intron FASTA to be generated
  -c1 T2C               Path to generate cDNA transcripts-to-capture
  -c2 T2C               Path to generate intron transcripts-to-capture
```

repository: pachterlab/kallistobustools

repo_name: pachterlab/kallistobustools


text:
JSONRPC server and client
=========================
Jsonrpc 2.0 for PHP over HTTP(S).

[![Scrutinizer Code Quality](https://scrutinizer-ci.com/g/Veejayspb/jsonrpc/badges/quality-score.png?b=master)](https://scrutinizer-ci.com/g/Veejayspb/jsonrpc/?branch=master)

Examples
--------

### Server
At first you have to extend **veejay\jsonrpc\Api** class and add required methods:
```php
class MyApi extends Api
{
    public function myMethod(array $params)
    {
        extract($params);
        if (!isset($myParam)) {
            throw new Exception(Response::INVALID_PARAMS);
        }
        return 'some result with param: ' . $myParam;
    }
}
```
Then run **Server** with the following code:
```php
$server = new Server(new MyApi);
echo $response = $server->run();
```

### Client
```php
$client = new Client('https://jsonrpc/server/address');

$query = $client->query('myMethod', ['my_param' => 1]);
$client->notify('myMethod');

$client->send();
```
You will receive the response from **myMethod** in **$query** variable.

Requirements
------------
- PHP 7.2+

Installation
------------
```
composer require "veejay/jsonrpc"
```

repository: Veejayspb/jsonrpc

repo_name: Veejayspb/jsonrpc


text:
# User Agent Utils

A Java utility library for processing user-agent strings. Can be used to handle HTTP requests in real-time or to analyze log files.

## Difference from the original repo

Maintained by [Wiz Panda](https://wizpanda.com), India.

Since the original repo is not being maintained, we took time to clean this up and we are now maintaining it with the following changes:

1. All codes are formatted to use Spaces instead of Tabs
2. Using Gradle to build, test & release instead of MVN
3. groupId has been changed from `eu.bitwalker` to `com.wizpanda`
4. artifactId has been changed from `UserAgentUtils` to `user-agent-utils`

## Advice

A lot of user-agents lie about their identity. That makes UA sniffing a guessing game. On websites it is a better approach to detect
features using a javascript library like Modernizr (http://modernizr.com/). Instead of using browser switches, build sites and services
that are cross-platform/cross-device compatible.

## Javadoc

http://bitwalker.eu/user-agent-utils-snapshot/javadoc/index.html

## Installation

This library has been deployed at https://bintray.com/wizpanda/maven/user-agent-utils

### Gradle

```groovy
compile "com.wizpanda:user-agent-utils:0.0.3"
```

### Maven

```xml
<dependency>
   <groupId>com.wizpanda</groupId>
   <artifactId>user-agent-utils</artifactId>
   <version>0.0.3</version>
</dependency>
```

## FAQ

**1. Can I add new browsers or operating systems?**

Unfortunately not directly. This library uses enums to represent browsers and operating systems to make using it easy and readable.
Unfortunately the use of enums also has some disadvantages. You can make a pull request on trunk for a new browser or operating system
if all tests are still passing. The purpose of this library is not to detect every possible version, so you’ll have to provide the
business value for a change.

**2. How can I improve the performance of the user-agent parsing?**

When handling requests on a web-server, consider if you need both the browser and operating system or if one of the two gives you enough
information. As the parsing uses an ordered tree structure, performance depends a lot on the type of clients making the requests. The
most common browsers and operating systems will be parsed faster than exotic ones. Consider caching the results temporarily.

**3. Are there other libraries like this?**

When I started this project in 2010 there were no other libraries offering the features I was looking for. Currently there are both open
source as well as commercial solutions.

## Change Log

See [CHANGELOG.md](https://github.com/wizpanda/user-agent-utils/blob/master/CHANGELOG.md). For old change logs, see
[this](https://github.com/wizpanda/user-agent-utils/commit/66395c1c84f66ed613bfbe5768f80002625cf889) commit.

repository: wizpanda/user-agent-utils

gha_language: Java

repo_name: wizpanda/user-agent-utils


text:
# Building instructions

Run:

```bash
docker build ./ -t pegi3s/pydock3-builder
```

# Build log

- 3.0 - 26/07/2022 - Pedro Ferreira

gha_language: Dockerfile


text:
# Changelog
All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.0.0/)
and this project adheres to [Semantic
Versioning](http://semver.org/spec/v2.0.0.html).

## Unreleased

## [0.5.0] - 2023-02-09

## Changed
- Update sensu-plugin-sdk, use new option types
- Use github.com/sensu/core instead of github.com/sensu/sensu-go/api/core
- Propagate hostname verification skipping option to Sensu HTTP client

## [0.4.0] - 2022-12-02

### Changed
- Update Sensu Go and SDK dependencies with the correct modules
- Support PEM certificate

## [0.3.0] - 2020-03-19
- The handler now checks for the "deactivated" attribute after requesting node
information, and uses its presence to determine if the node does not exist.

## [0.2.0] - 2020-02-11

### Changed
- The Puppet node name can now be overridden using entities annotations

## [0.1.0] - 2020-02-11

### Added
- Initial release

repository: sensu/sensu-puppet-handler

gha_language: Go

repo_name: sensu/sensu-puppet-handler


text:
# Mildbot
## Introduction

The purpose of this is to create an easy to use interface for bot creation, allowing users to create their own custom experience without a background in programming.

This project is currently not in a working state, so don't expect to get this up and running any time soon.

## Features
* Nothing yet

## Desired Features
* Plugin based functionality, allowing for easy expansion.
* Generic usage of API wrappers, making it easy to transfer your bot between two different platforms.
* Compilation of plugins create the functionality of your bot.
* Zero coding requirements for simple bots.
* Web based control panel to keep things friendly while allowing for easy remote administration and compatibility with multiple platforms.

repository: foxfluff/mildbot

repo_name: foxfluff/mildbot


text:
# Open AI Arena

The purpose of this project is to research Artificial Intelligence and Reinforcement Learning.

In the AI Arena, multiple agents can interact with a single environment. After sending its action, each each agent will receive a reward. This allows agents to learn, improve their policy and to adapt to each other.

This setting raises interesting questions.

* How do multiple agents interact and adapt to each other?
Will they compete or cooperate?
* How will they deal with a Nash-equilibrium? Do they get stuck in a prisoners dillema or can Artificial Intelligence with enough exploration learn to escape the dillema?

## The Arena

Competition drives progress. That's why the arena is not only for 'bots' to compete with each other. Anyone is free to derive from this code to develop a multi player game and setup an AI tournament for developers and AI researchers to compete with each other.

The Arena is implemented in C++, but is very flexible. Agents can be implemented in any programming language. They interact with the environment via stdout.
An important feature of the environment is that after each action, every agent or 'bot' will receive a reward. This way bots can learn and improve as they play, just like in a classical reinforcement learning setup.
Furthermore, instead of playing one episode or 'game' at a time. The environment lets bots play any number of consecutive games. Each bot can remember its state and what it has learned, to allow it to improve game after game.

This adds a new aspect to the challenge. Instead of simply seeing who is best in a single game，the meta-challenge is to see which bot is the fastest learning and fastest to adapt to its opponents.

See if you can defeat the random bot in the [example game](./environment/chickenpoker/README.md) that is already implemented. Or better, derive from the code to create your own multi player AI challenge.

### Credits

This project is inspired by [Halite](https://halite.io/index.php) which was a particularly fun AI programming challenge. Indeed some of the code in the NetworkAgent.cpp is derived from [that project](https://github.com/HaliteChallenge/Halite).


text:
# 8.13. Versioned storages

- [Manage versioned storages](#manage-versioned-storages)
    - [Create versioned storage](#create-versioned-storage)
    - [View and edit content](#view-and-edit-content)
        - [Create a folder/file](#create-a-folderfile)
        - [Edit file content](#edit-file-content)
        - [Rename a file/folder](#rename-a-filefolder)
        - [Remove a file/folder](#remove-a-filefolder)
- [Version control](#version-control)
    - [Commit history of the file](#commit-history-of-the-file)
        - [Download a specific version](#download-a-specific-version)
        - [Revert to a specifid version](#revert-to-a-specifid-version)
        - [View diffs](#view-diffs)
    - [Commit history of the folder](#commit-history-of-the-folder)
    - [Filter commit history](#filter-commit-history)
    - [Generate changes report](#generate-changes-report)
- [GIT operations with versioned storages](#git-operations-with-versioned-storages)
    - [Load versioned storage content to the instance](#load-versioned-storage-content-to-the-instance)
        - [Launch a run with the content cloning](#launch-a-run-with-the-content-cloning)
        - [Clone content to the already running instance](#clone-content-to-the-already-running-instance)
    - [View diffs of changed cloned content](#view-diffs-of-changed-cloned-content)
    - [Save changed content from the run to the versioned storage](#save-changed-content-from-the-run-to-the-versioned-storage)
        - [Save changed content with the conflict resolving](#save-changed-content-with-the-conflict-resolving)
    - [Update cloned content in the run](#update-cloned-content-in-the-run)
        - [Refresh cloned content](#refresh-cloned-content)
        - [Change the revision for the content](#change-the-revision-for-the-content)

In some cases, there is not enough to only store data in storages/place computation results there but also there is a request for the full value system of the revision control of stored data - to view revisions, history of changes, diffs between revisions.
So far, for separate storages types (e.g. `AWS` s3 buckets), there is the ability to enable the [versioning](8.4._Control_File_versions.md) option. But it is not the same. Versioning allows to manage the versions of the certain file, not the revisions of the full storage, which revision can contain changes of several files or folders.
For the needs of full version control of the storing data, there is a special storage type in the **Cloud Pipeline** - "Versioned" storage.

These storages are GitLab repositories under the hood, all changes performed in their data are versioned. Users can view the history of changes, diffs, etc.
Such storages can be also mounted during the runs, data can be used for the computations and results can be comitted back to such storages - with all the benefits of a version control system.

## Manage versioned storages

### Create versioned storage

To create versioned storage:

1. Navigate to the folder where you want to create data storage.
2. Click **+ Create** → **VERSIONED STORAGE**:
    ![CP_VersionedStorages](attachments/VersionedStorages_01.png)
3. The pop-up of the versioned Storage creation will appear:
    ![CP_VersionedStorages](attachments/VersionedStorages_02.png)
4. Specify the name of the creating storage (_mandatory_) and description (_optionally_), e.g.:
    ![CP_VersionedStorages](attachments/VersionedStorages_03.png)
5. By default, the creating versioned storage will be empty.
    But you may define a folders structure for it before the creation:
    - set the "**Predefined folder structure**" checkbox
    - in the appeared field, specify a structure you want the storage will have:
    ![CP_VersionedStorages](attachments/VersionedStorages_04.png)
    - structure shall include folder paths in format: `<folder1>/<subfolder1>/...` (each subfolder is is delimited by `/`), each new folder on the same level from the root of the storage shall starts from the new line, e.g.:
    ![CP_VersionedStorages](attachments/VersionedStorages_05.png)
6. Click the **Create** button to confirm.
7. Just-created versioned storage will appear in the folder:
    ![CP_VersionedStorages](attachments/VersionedStorages_06.png)
8. If you have predefined the structure - you may see it is created as well:
    ![CP_VersionedStorages](attachments/VersionedStorages_07.png)

> **_Note_**: not to confuse with regular object storages, versioned storage icons (and all objects inside them) are colorized in blue color:
>   ![CP_VersionedStorages](attachments/VersionedStorages_08.png)

### View and edit content

The view of the versioned storage is similar to regular [data storage](8._Manage_Data_Storage.md#8-manage-data-storage) with some differences:
    ![CP_VersionedStorages](attachments/VersionedStorages_09.png)

- for each file/folder in the storage, the following columns are displayed:
    - _Name_ - file/folder name
    - _Size_ - file size (empty for folders)
    - _Revision_ - latest revision (SHA-1 hash of the latest commit) touched that file/folder
    - _Date changed_ - date and time of the latest commit touched that file/folder
    - _Author_ - user name who performed the latest commit touched that file/folder
    - _Message_ - message of the latest commit touched that file/folder
- for each file in the storage, there are additional buttons similar to regular storage - to download file to the local workstation, to rename the file and to remove the file from the storage
- for each folder in the storage, there are additional buttons similar to regular storage - to rename the folder and to remove the folder from the storage
- **RUN** button - allows to run the tool with cloning of the current versioned storage into the instance - see details [below](#launch-a-run-with-the-content-cloning)
- **Generate report** button - allows to configure and then download the report of the storage usage (commit history, diffs, etc.) - see details [below](#generate-changes-report)
- **Show history** button - allows to open the panel with commit history info of the current versioned storage or selected folder - see details [below](#commit-history-of-the-folder)
- settings button ("**gear**" icon) - allows to open the seetings pop-up where:
    - versioned storage can be edited (name and description can be changed) or removed:
    ![CP_VersionedStorages](attachments/VersionedStorages_10.png)
    - permissions on the storage can be configured:
    ![CP_VersionedStorages](attachments/VersionedStorages_11.png)
- buttons to create file/folder and to upload data are similar to the corresponding ones in regular storages

#### Create a folder/file

To create a folder:

1. Click "**+ Create**" button in the versioned storage
2. In the list, select the **Folder** item:
    ![CP_VersionedStorages](attachments/VersionedStorages_12.png)
3. The pop-up will appear to specify a new folder name and commit message:
    ![CP_VersionedStorages](attachments/VersionedStorages_13.png)
4. Specify a folder name (_mandatory_).
    The commit message may be omitted. If it is not specified - it will be set automatically.
    Click **OK** button to confirm:
    ![CP_VersionedStorages](attachments/VersionedStorages_14.png)
5. After the creation, a new revision of the storage will be created (contains only differences with the previous revision).
    Just-created folder will appear in the storage:
    ![CP_VersionedStorages](attachments/VersionedStorages_15.png)

To create a file:

1. Click "**+ Create**" button in the versioned storage
2. In the list, select the **File** item:
    ![CP_VersionedStorages](attachments/VersionedStorages_16.png)
3. The pop-up will appear to specify a new file name and commit message.
4. Specify a file name (_mandatory_).
    The commit message may be omitted. If it is not specified - it will be set automatically.
    Click **OK** button to confirm, e.g.:
    ![CP_VersionedStorages](attachments/VersionedStorages_17.png)
5. After the creation, a new revision of the storage will be created (contains only differences with the previous revision).
    Just-created file will appear in the storage:
    ![CP_VersionedStorages](attachments/VersionedStorages_18.png)

> **_Note_**: during the file creation in the versioned storage, you are not able to specify the file content simultaneously (as it is possible for regular storages) - therefore file is created with the zero-size. To add a file content - [edit](#edit-file-content) it.

Uploading of the data is similar to [regular](8.2._Upload_Download_data.md#upload-data) storages.
After the upload, a new revision of the storage is being created. The commit message for uploaded files is being set automatically, e.g.:
    ![CP_VersionedStorages](attachments/VersionedStorages_19.png)

#### Edit file content

To edit a text file:

1. Click the file in the versioned storage
2. File preview will be opened on the right. In case of the file is large you will see only its part
3. Click the "**Expand**" icon in the upper right of the preview section, e.g.:
    ![CP_VersionedStorages](attachments/VersionedStorages_20.png)
4. Pop-up with the file content will appear:
    ![CP_VersionedStorages](attachments/VersionedStorages_21.png)
    Click the **Edit** button to enable the edit-mode for the file.
5. Change the file content and click the **Save** to confirm changes, e.g.:
    ![CP_VersionedStorages](attachments/VersionedStorages_22.png)
6. Specify the commit message in the appeared pop-up, e.g.:
    ![CP_VersionedStorages](attachments/VersionedStorages_23.png)
    Click the **Commit** button to confirm.
7. After saving, a new revision of the storage will be created:
    ![CP_VersionedStorages](attachments/VersionedStorages_24.png)

> **_Note_**: binary file can not be edited by the described way. In this case, only download hyperlink is shown for such files instead of the preview, e.g.:
>    ![CP_VersionedStorages](attachments/VersionedStorages_25.png)

#### Rename a file/folder

To rename a file/folder:

1. Click the **Rename** button in the row of the file/folder of the versioned storage
2. In the appeared pop-up, specify a new name and commit message.
    The commit message may be omitted. If it is not specified - it will be set automatically.
    Click **OK** button to confirm:
    ![CP_VersionedStorages](attachments/VersionedStorages_26.png)
3. After saving, a new revision of the storage will be created.
    File/folder will be renamed:
    ![CP_VersionedStorages](attachments/VersionedStorages_27.png)

#### Remove a file/folder

To remove a file/folder:

1. Click the **Remove** button in the row of the file/folder of the versioned storage
2. In the appeared pop-up, specify a commit message.
    The commit message may be omitted. If it is not specified - it will be set automatically.
    Click the **Delete** button to confirm:
    ![CP_VersionedStorages](attachments/VersionedStorages_28.png)
3. After saving, a new revision of the storage will be created. File/folder will be removed

> **_Note_**: removing of the folder also deletes all child files and subfolders.

***

## Version control

Due to that versioned storage is a Git repository by the fact, so one of the important advantages of versioned storages in condition with regular object storages - ability to view commit history and all changes that were performed with the data in details.

### Commit history of the file

You can view the commit history of the file in the versioned storage - i.e. history of all commits that touched this file.

To open the commit history of the file, click it. The commit history will be displayed under the file preview section, e.g.:
    ![CP_VersionedStorages](attachments/VersionedStorages_29.png)

Commit history contains a list of records. Each record corresponds to one commit that touched the selected file. List of commits is sorted from the last commit to earlier ones.
Each record includes:

- commit message
- commit SHA-1 hash
- user name - author of the commit
- date and time when commit (changes) was performed
- block of buttons:
    - ![CP_VersionedStorages](attachments/VersionedStorages_31.png) - **Revert** button - to revert the content of the current file to the selected commit
    - ![CP_VersionedStorages](attachments/VersionedStorages_32.png) - **Download version** button - to view/download revert version of the current file corresponding to the selected commit
    - ![CP_VersionedStorages](attachments/VersionedStorages_33.png) - **Show diffs** button - to view diffs between the content of the current file in the selected commit and in the previous commit

![CP_VersionedStorages](attachments/VersionedStorages_30.png)

#### Download a specific version

To download a specific version of the file in the versioned storage:

1. Click the file to open its commit history
2. Find the commit
3. Click the **Download version** button for the commit, e.g.:
    ![CP_VersionedStorages](attachments/VersionedStorages_34.png)
4. The file content in the selected commit will be displayed:
    ![CP_VersionedStorages](attachments/VersionedStorages_35.png)
5. Click the **Download** button in the upper side of the pop-up

#### Revert to a specifid version

To revert to a specific version of the file in the versioned storage:

1. Click the file to open its commit history
2. Find the commit
3. Click the **Revert** button for the commit, e.g.:
    ![CP_VersionedStorages](attachments/VersionedStorages_36.png)
4. Pop-up will appear to specify a commit message - for the operation that will revert the current state of the file to the selected commit.
    The commit message may be omitted. If it is not specified - it will be set automatically.
    Click the **Revert** button to confirm:
    ![CP_VersionedStorages](attachments/VersionedStorages_37.png)
5. After the operation:
    - content of the file will be reverted to the selected commit
    - new commit will appear in the commit history
    ![CP_VersionedStorages](attachments/VersionedStorages_38.png)

**_Note_**: **Revert** button is available for any non-latest commit.

#### View diffs

To view differences of a specific file version conditionally to its previous version:

1. Click the file to open its commit history
2. Find the commit
3. Click the **Show diffs** button for the commit, e.g.:
    ![CP_VersionedStorages](attachments/VersionedStorages_39.png)
4. The pop-up will be opened with diffs between file version in the selected commit and in the previous commit:
    ![CP_VersionedStorages](attachments/VersionedStorages_40.png)

Differences pop-up includes:

- selected commit's hash
- file name
- state of changes that were performed with the file in the commit. Possible variants:
    - _ADDED_ - new file was created
    - _CHANGED_ - existing file was edited
    - _DELETED_ - file was removed
    - _RENAMED_ - file was renamed
- section with details of changes:
    - new added rows are shown in green color, e.g.:
        ![CP_VersionedStorages](attachments/VersionedStorages_43.png)
    - rows that were removed are shown in red color, e.g.:
        ![CP_VersionedStorages](attachments/VersionedStorages_44.png)
    - not changed rows or auxiliary info are shown without filling, e.g. changes in a binary file:
        ![CP_VersionedStorages](attachments/VersionedStorages_41.png)
        or new empty text file creation:
        ![CP_VersionedStorages](attachments/VersionedStorages_42.png)

### Commit history of the folder

You can view the commit history of any folder in the versioned storage (including the root folder) - i.e. history of all commits that touched files in this folder and in its subfolders.

To view the commit history of the folder in the versioned storage:

1. Open the folder
2. Click the "**Show history**" button in the right upper corner.
    The commit history will appear on the right side, "**Show history**" button will be renamed to "**Hide history**" e.g.:
    ![CP_VersionedStorages](attachments/VersionedStorages_45.png)

Commit history contains a list of records. Each record corresponds to one commit that touched the current folder's files. List of commits is sorted from the last commit to earlier ones.
Each record includes:

- commit message
- commit SHA-1 hash
- user name - author of the commit
- date and time when commit (changes) was performed
- **Show diffs** button - ![CP_VersionedStorages](attachments/VersionedStorages_33.png) - to view diffs between the content of the folder in the selected commit and in the previous commit. Displaying of diffs is similar to separate files, you can see examples [above](#view-diffs).

### Filter commit history

You may filter the commit history (both for a separate file and for a folder) - for example, to find some specific commits.
To open the **Filter** panel - click the corresponding button in the right upper corner of the commit history section - ![CP_VersionedStorages](attachments/VersionedStorages_46.png)

**Filter** panel has view:
    ![CP_VersionedStorages](attachments/VersionedStorages_47.png)

Here, the following filters for the commit history can be configured:

- by _Author_ - you may select one or several users to filter revisions (commits) by their author(s).
    By default, commits of all authors are displayed.
- by _Date_ - you may select period (date `From` and date `To` - note that any of the date may be omitted) to filter revisions (commits) by their dates.
    By default, commits for all periods of the object existence are displayed.
- by _File type_ - you may specify file type(s) to filter the revisions (commits) list by only the ones that touched files of the specified type(s).
    File types shall be specified in a plain text format, comma-separated, simple masks are supported. Example: `csv,ma*,md`.
    By default, commits for all files are displayed.

Once filters are configured, click the **Apply** button to confirm, e.g.:
    ![CP_VersionedStorages](attachments/VersionedStorages_48.png)
The commit history will be updated according to the configured filters:
    ![CP_VersionedStorages](attachments/VersionedStorages_49.png)

To reset (clear) configured filters:

1. Click the **Filter** button.
2. At the **Filter** panel, click the **Reset** button:
    ![CP_VersionedStorages](attachments/VersionedStorages_50.png)
3. Filters will be reset. The commit history will be updated.

### Generate changes report

For the versioned storages, there is the ability to generate and download reports.
Reports contain commit history of the [current folder](#commit-history-of-the-folder) in the versioned storage and also can include diffs between commits.
Such reports can be downloaded in Microsoft Word format (`docx` file).

To generate a report:

1. Open the folder in the versioned storage.
2. Click the "**Generate report**" button in the right upper corner of the page.
3. "**Generate report**" form will appear:
    ![CP_VersionedStorages](attachments/VersionedStorages_51.png)
4. You may configure filters - only commits that match such filters will be included in the report (by default - if no filters are set, all commits will be included).
    These filters are fully the same as in the [**Filter** panel](#filter-commit-history):
    - by _Author_ - to restrict the list of reported commits by their author(s)
    - by _Date_ - to restrict the list of reported commits by date of their creation
    - by _File type_ - to restrict the list of reported commits according to included file types
5. You may additionally include differences between files in each commit - by set the corresponding checkbox "**Include file diffs**":
    ![CP_VersionedStorages](attachments/VersionedStorages_54.png)
    In this case, you may select how to split changes that will be include to the report:
    - by **revision** - changes will be split by commits, i.e. from the recent commit to older ones, in each commit all files changes touched by this commit are included
    - by **files** - changes will be split by all changed files, i.e. for each changed file all commits that touched this file are included
    - additionally, you may set the checkbox "**Save changes separately**":
        - in this case (no matter which split-mode is selected), changes will be saved in separate files - i.e. one report-file per each commit or one report-file per each changed file
        - summary report will be downloaded as an archive
6. Once settings are configured, click the "**Download report**" button.
7. Report will be downloaded automatically:
    ![CP_VersionedStorages](attachments/VersionedStorages_52.png)

Example of the part of the report without included diffs:
    ![CP_VersionedStorages](attachments/VersionedStorages_53.png)

Example of the part of the report with included diffs (changes split by _commits_):
    ![CP_VersionedStorages](attachments/VersionedStorages_55.png)
    In the shown commit, one file was changed.

Example of the part of the report with included diffs (changes split by _files_):
    ![CP_VersionedStorages](attachments/VersionedStorages_56.png)
    Shown file was changed in 3 commits.

Report itself is being generated from the `docx`-format template.
Platform has the "base" template but system admin has the ability to load own template and replace the "base" one.
Template contains plain text and a set of predefined keywords that are replaced by actual values of the current versioned storage's data during the report generation according to the configured report filters.
By this way, report view, its text blocks, tables, fonts, formats, etc. can be preconfigured for the customer needs.

***

## GIT operations with versioned storages

Users have the ability to launch runs using versioned storages.
Users have the access to the version storages during the run - similarly as to the folder of any mounted object storage.
Users have the ability to read and write data (according to the permissions) to the version storages from inside the runs.

But versioned storages have some differences to the regular object storages used in runs - especially in question of data saving and resolving conflicts.

To manage versioning operations from active runs, there are additional controls:

- at the main Dashboard, in the "Active runs" panel, it is **VCS** (Version Control Storages) item - it is available when hovering any fully initialized run's tile, e.g.:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_09.png)
- at the "Run logs" page, it is **VERSIONED STORAGE** item - it is available for any fully initialized run, e.g.:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_10.png)

Both these items are identical to each other. In our examples below we will use the **VCS** control from the main Dashboard, in generally.
By click such items, additional menu appears - its content may vary in different cases.
Let's view main scenarios of using versioned storages in running jobs.

### Load versioned storage content to the instance

There are two possible ways to load versioned storage content to the running instance:

- launch the run from the versioned storage page with the automatic content cloning during the run initialization
- clone the versioned storage content to the already running instance

#### Launch a run with the content cloning

In this case, content of the selected versioned storage is being cloned during the run initialization.
To launch a run from the versioned storage page:

1. Open the versioned storage page.
2. Click the **RUN** button in the right upper corner of the page:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_01.png)
3. The pop-up will appear:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_02.png)
    Here, the list of tools is shown. By default, this list contains tools from the user [personal group](../10_Manage_Tools/10._Manage_Tools.md#personal-docker-repository-tool-group).
4. Click the tool you wish to run with the versioned storage, e.g.:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_03.png)
    If needed, you may select the tool version from the appeared dropdown list in the tool tile.
5. If you want to customize the tool settings (or you do not have the desired tool in the list) - you may configure the tool for the launch manually:
    - click the **Run custom** button in the left bottom corner of the pop-up:
        ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_04.png)
    - the **Launch** form will appear - similar to the one that appears before the [pipeline launch](../06_Manage_Pipeline/6.2._Launch_a_pipeline.md#62-launch-a-pipeline):
        ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_05.png)
    - you may specify options as you want
6. Click the **Launch** button to confirm the run.
7. Run of the selected tool will be launched:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_06.png)
8. Selected versioned storage content will be automatically cloned into the running instance (during the run initialization) - by the path `/versioned-data/{versioned_storage_name}`.
    Once the run is fully initialized, you may open the [SSH terminal](../15_Interactive_services/15.2._Using_Terminal_access.md#using-terminal-access) for the launched run and check that the versioned storage content was cloned:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_07.png)
    Or via the [filesystem browser](../15_Interactive_services/15.3._Expose_node_filesystem.md#153-expose-node-filesystem):
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_08.png)
9. Click the **VERSIONED STORAGE** item at the "Run logs" page - cloned versioned storage will be displayed with its actions list:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_16.png)

#### Clone content to the already running instance

You may clone the versioned storage content to the already running instance:

1. At the main Dashboard, hover over the active run's tile to which instance you want to clone the version storage content.
    Please note, that run shall be fully initialized.
2. Click the **VCS** control.
3. In the appeared menu, click the **Clone** item, e.g.:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_11.png)
4. The pop-up will appear:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_12.png)
    Here, the full list of available versioned storages is shown.
5. Click the storage you want to clone to the current run, e.g.:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_13.png)
    In the row of the selected storage, the field will appear where you may select the specific commit of the versioned storage you want to clone:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_14.png)
    By default, the recent commit is selected.
    Click the **SELECT** button to confirm.
6. Selected versioned storage content will be cloned to the running instance:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_15.png)
7. Click the **VCS** control for the run - cloned versioned storage will be displayed with its actions list:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_17.png)
8. Also as shown in the section above, cloned versioned storage content is available in the running instance by the path `/versioned-data/{versioned_storage_name}`.

You may clone any count of versioned storages to the running instance by the described way.
For example:

1. Click the **VCS** control for the run with the previously cloned storage:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_18.png)
2. In the appeared pop-up, select a versioned storage to clone, e.g.:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_19.png)
    If there are versioned storages previously cloned to that run - they are also displayed in the list, but can not be selected repeatedly.
3. After confirmation, all cloned versioned storages will be displayed in the list by click the **VCS** control:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_20.png)
4. And all cloned versioned storages will be available by the path `/versioned-data/{versioned_storage_name}`:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_21.png)

### View diffs of changed cloned content

At any point after the versioned storage was cloned to the running instance, you can request the diffs for that storage.
These diffs will show all changes made by the current user in files of cloned versioned storage - i.e. differences between commit of the versioned storage that was cloned to the running instance and the current state of files in that cloned folder.

To view diffs from the running instance with the cloned versioned storage:

1. At the main Dashboard, hover over the active run's tile to which instance the versioned storage was cloned.
2. Click the **VCS** control.
3. In the appeared menu, select the versioned storage (if there are several ones) and click the **Diffs** item for it, e.g.:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_22.png)
    Please note, that if there are no changes in the cloned versioned storage were made - this item will be  visible in the menu but disabled.
4. The diffs pop-up will be opened, e.g.:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_23.png)
    Here, the full list of your changes in files in comparing with the cloned version of the selected versioned storage is shown.
    Changes are split by files. Displaying of diffs for each file is similar to the described in one of the section [above](#view-diffs).

### Save changed content from the run to the versioned storage

At any point after the versioned storage was cloned to the running instance, you can "save" changes made in the cloned content to the origin versioned storage.
Please note, if you will just stop the run with the cloned versioned storage without "saving" operation - all changes you performed in the cloned folder of the versioned storage will dissapear without any posibilities to restore the data.

To perform the "save" operation from the running instance with the cloned versioned storage:

1. At the main Dashboard, hover over the active run's tile to which instance the versioned storage was cloned.
2. Click the **VCS** control.
3. In the appeared menu, select the versioned storage (if there are several ones) and click the **Save** item for it, e.g.:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_24.png)
    Please note, that if there are no changes in the cloned versioned storage were made - this item will be  visible in the menu but disabled.
4. The pop-up will be opened, e.g.:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_25.png)
5. Specify a commit message.
6. View details of performed changes - here, the full list of your changes in files in comparing with the cloned version of the selected versioned storage is shown (similar to [Diffs](#view-diffs-of-changed-cloned-content) option).
    You may expand details by click the file name. Displaying of diffs for each file is similar to the described in one of the section [above](#view-diffs):
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_26.png)
7. By default, all changed files from the cloned versioned storage are included to the preparing commit ("Save" operation).
    But you can select only files you want to include to the commit - by the checkboxes near the file names, e.g.:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_27.png)
    Or via the buttons above the list:
    - **Select all** - to include all changed files to the preparing commit
    - **Clear selection** - to exclude all changed files from the preparing commit
    Please note, if you will exclude some file(s) from the preparing commit, you can include these files in another commit later.
8. Once the commit message is specified and files to commit are defined - click the **Commit** button to confirm, e.g.:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_28.png)
    The system tries to perform corresponding Git actions to origin versioned storage.
9. Changed files will be "saved" to the origin versioned storage:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_29.png)
    You can check it from the versioned storage page:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_30.png)
10. Changed files that were not included in the commit are still shown in **Diffs**:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_31.png)
    And can be "saved" in another commit:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_32.png)

#### Save changed content with the conflict resolving

There may be cases, when any conflict is detected during the "save" operation attempt.
Conflict may appears, for example, when you have cloned versioned storage to the run, made some changes and another user during this period of time made own changes to the same file(s) as in your current run and managed to "save" these changes (perform commit) to the origin versioned storage.

Let's imagine, that there are two users (you and somebody else) that both cloned the same versioned storage to their runs and perform changes in the same files, touching the same parts of these files.
Herewith, the second user managed to "save" these changes (performed a commit to the origin versioned storage).

So, when you will try to "save" changes by steps described [above](#save-changed-content-from-the-run-to-the-versioned-storage):

1. The pop-up before the saving will have view like:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_33.png)
2. Once the **Commit** button is clicked, the conflict error will occur and "**Resolve conflicts**" pop-up will appear:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_34.png)
3. This pop-up contains:
    - list of conflicting files (left panel) - please note that changed non-conflicting files are not shown here, they will be saved without additional resolving
    - 3 columns with the content of conflicting versions of the selected file:
        - "**_Your changes_**" (left) - column shows changed state of the conflicting file (current state of the file in your run that you have tried to save)
        - "**_Changes from remote_**" (right) - column shows the state of the conflicting file from the most recent revision of that file. In our example - it is changed file that second user has saved to the origin versioned  storage
        - "**_Result_**" (center) - column shows the merging state (result) of the conflict resolving. When you will resolve the conflict, the version that will be saved will be shown here
    - all changes are highlighted:
        - _conflicting_ changes are in red color, i.e. in both versions the same part of the file is touched:
        ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_35.png)
        - _non-conflicting_ changes (changes that are not touched the same parts):
            - new added parts and places where they mya be inserted are in green color e.g.:
            ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_36.png)
            - changed existing parts are in yellow color e.g.:
            ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_37.png)
    - buttons to revert/repeat performed actions during the conflict resolving: ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_43.png)
    - buttons to apply only _non-conflicting_ changes as a batch:
        - ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_40.png) - to apply all _non-conflicting_ changes from your changed version of the file. They will be "copied" to the central column, i.e. to the version that will be saved after the conflict resolving
        - ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_42.png) - to apply all _non-conflicting_ changes from the updated current version of the file in the origin versioned storage (i.e. in our example, it is the version saved by the second user). Changes will be "copied" to the central column, i.e. to the version that will be saved after the conflict resolving
        - ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_41.png) - to apply all _non-conflicting_ changes from both file versions - yours, prepared for the saving, and theirs, from the updated origin versioned storage
    - buttons to accept one of the full versions of the conflicting file as a conflict resolve:
        - ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_38.png) - to accept all changes (_conflicting_ and _non-conflicting_) fully from your version of the file
        - ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_39.png) - to accept all changes (_conflicting_ and _non-conflicting_) fully from the updated current version of the file in the origin versioned storage (i.e. in our example, it is the version saved by the second user)
4. You shall resolve all changes in each conflicting file.
    You may resolve any change/conflict manually or use buttons for batch resolving that described in the previous item.
    For manually resolving, there are abilities for each change/conflict in the file:
    - to accept it - by the arrows icon near the change, e.g. ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_44.png) - by this action, the corresponding change will be "copied" to the central column, highlighting of the change will disappear
    - to decline it - by the cross icon near the change, e.g. ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_45.png) - by this action, the corresponding change will be declined, i.e. will be "ignored" in the central column, highlighting of the change will also disappear
    - to change the text manually (e.g., if both versions are not satisfied) - for that, set the cursor to the change highlighting area in the central column and specify a new text
5. Let's view different options:
    - manually accept _non-conflicting_ change from your version by click the arrows icon:
        ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_46.png)
        Changed part from your version will appear in the central column, highlighting of the change will disappear:
        ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_47.png)
    - batch-apply of all _non-conflicting_ changes from the origin versioned storage (saved by the second user):
        ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_48.png)
        All _non-conflicting_ changes from remote version will appear in the central column, their highlighting will disappear:
        ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_49.png)
    - manually decline _conflicting_ change from your version:
        ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_50.png)
        Change from your version will be declined, highlighting of the change will disappear:
        ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_51.png)
    - click the conflict area in the central column:
        ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_52.png)
        Specify a new text as you want, e.g.:
        ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_53.png)
    - to finish resolving, decline _conflicting_ change from the remote version:
        ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_54.png)
6. Once all changes and conflicts in the selected file are resolved, the corresponding info will appear in the upper side of the pop-up and in the files list:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_55.png)
    The version of the file displayed in the central column (_Result_) will be saved in the origin versioned storage.
7. To proceed the saving process, all conflicts in all files shall be resolved.
    Therefore, open one-by-one each conflicting file in the list and resolve changes using instructions described above:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_56.png)
8. In case of conflicting binary files, there is no ability to resolve each change:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_57.png)
    You shall only select which version to accept for the saving - your changed version of this file or updated version from the origin versioned storage (i.e. in our example, it is the version saved by the second user).
9. Once all conflicts in all files are resolved, the button **Resolve** becomes available:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_58.png)
    Click it to finish the saving process.
10. Corresponding messages will appear:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_59.png)
11. You can check that changes were saved - from the versioned storage page:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_60.png)

### Update cloned content in the run

At any point after the versioned storage was cloned to the running instance, you can update the cloned content in the running instance:

- "refresh" cloned content up to the latest revision (most recent) of the versioned storage. It may be useful as the origin content of the versioned storage could be changed by other users during your run.
- also, you can change the revision to any non-latest one - just to "view" the state of the versioned storage in a certain revision.

#### Refresh cloned content

To "refresh" cloned content up to the latest revision (most recent):

1. At the main Dashboard, hover over the active run's tile to which instance the versioned storage was cloned.
2. Click the **VCS** control.
3. In the appeared menu, select the versioned storage (if there are several ones) and click the **Refresh** item for it, e.g.:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_61.png)
4. The corresponding message will appear:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_62.png)
5. Once the refresh is performed, confirmation will appear:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_63.png)

Please note, that if you made changes in cloned files and did not save them, then 2 scenario are possible:

- if there are no conflicts between your changed unsaved files and files that were updated in the origin versioned storage - in such case:
    - revision version for the cloned content will be updated to the latest without issues
    - changed unsaved files in the cloned content will remain in their state, you may proceed work with them and then save, for example
- if there are conflicts between your changed unsaved files and files that were updated in the origin versioned storage - in such case:
    - the error of the refresh unable will occur:
        ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_64.png)
    - the pop-up will appear to resolve the conflicts
    - revision version for the cloned content will not be updated till you will not resolve the conflict as described in the section [above](#save-changed-content-with-the-conflict-resolving).
    When you will resolve conflicts, new merge commit will be created and your cloned content will be update to this version (latest), previously conflicted changes will be saved how they were resolved.

#### Change the revision for the content

To change the revision of the cloned content to some non-latest one:

1. At the main Dashboard, hover over the active run's tile to which instance the versioned storage was cloned.
2. Click the **VCS** control.
3. In the appeared menu, select the versioned storage (if there are several ones) and click the **Checkout revision** item for it, e.g.:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_65.png)
4. Pop-up with the dropdown list of all storage's revisions will appear:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_66.png)
5. Click the dropdown list and select the revision, e.g.:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_67.png)
    **_Note_**: current revision of the storage content is specified with the bold font.
6. To confirm the checkout, click the "**Change Revision**" button:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_68.png)
7. The corresponding message will appear:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_69.png)

Please note, if you have changed the revision to any non-latest one and then change some files, these new changes can not be saved by the way described in the [**Save**](#save-changed-content-from-the-run-to-the-versioned-storage) section, the corresponding item in the **VSC** menu will be disabled:
    ![CP_VersionedStorages_GitOperations](attachments/VersionedStoragesGIT_70.png)

In this case, to save made changes you may:

- [refresh the content revision](#refresh-cloned-content) up to the latest version and then [save](#save-changed-content-from-the-run-to-the-versioned-storage) changes
- or change the revision as described in the current section but to the latest one and then [save](#save-changed-content-from-the-run-to-the-versioned-storage) changes

Additionally note, if the revision of the cloned content is the latest, and you make any changes of the content and then change the revision to any non-latest - your unsaved changes will be lost. To avoid this, at the beginning, save changes and only then change the revision to non-latest.

repository: epam/cloud-pipeline

branch_name: refs/heads/develop

repo_name: epam/cloud-pipeline


text:
# Scripts

This folder contains a Python scripts for working with manifest files. Currently, there is just one script, `validate.py`. This is a command line tool for validating manifests against the schema. A typical usage might be something like

```
python validate.py ../schema/v2.0/Corpus.schema.json ../schema/v2.0/tests/Corpus.json
```

For further information, see [Working with the Schema](https://whatevery1says.github.io/manifest/working-with-the-schema/).

gha_language: Python


text:
reboot
=========

A straight forward role that reboots the server.

Requirements
------------

Any pre-requisites that may not be covered by Ansible itself or the role should be mentioned here. For instance, if the role uses the EC2 module, it may be a good idea to mention in this section that the boto package is required.

Role Variables
--------------

None.

Dependencies
------------

No dependencies.

Example Playbook
----------------

Including an example of how to use your role (for instance, with variables passed in as parameters) is always nice for users too:

    - hosts: servers
      roles:
         - { role: opuk.reboot }

License
-------

MIT

repository: opuk/ansible-opuk-reboot

repo_name: opuk/ansible-opuk-reboot