Dexter  Goodwin

Dexter Goodwin

1661227680

Conventional Changelog Action

Conventional Changelog action

This action will bump version, tag commit and generate a changelog with conventional commits.

Inputs

  • Optional github-token: Github token, if different permissions required than from checkout.
  • Optional git-message: Commit message that is used when committing the changelog.
  • Optional git-user-name: The git user.name to use for the commit. Default Conventional Changelog Action
  • Optional git-user-email: The git user.email to use for the commit. Default conventional.changelog.action@github.com
  • Optional git-pull-method: The git pull method used when pulling all changes from remote. Default --ff-only
  • Optional git-push: Push all the GIT changes. Default true
  • Optional preset: Preset that is used from conventional commits. Default angular.
  • Optional tag-prefix: Prefix for the git tags. Default v.
  • Optional output-file: File to output the changelog to. Default CHANGELOG.md, when providing 'false' no file will be generated / updated.
  • Optional release-count: Number of releases to preserve in changelog. Default 5, use 0 to regenerate all.
  • Optional version-file: The path to the file that contains the version to bump. Default ./package.json.
  • Optional version-path: The place inside the version file to bump. Default version.
  • Optional skip-on-empty: Boolean to specify if you want to skip empty release (no-changelog generated). This case occured when you push chore commit with angular for example. Default 'true'.
  • Optional skip-version-file: Do not update the version file. Default 'false'.
  • Optional skip-commit: Do not create a release commit. Default 'false'.
  • Optional pre-commit: Path to the pre-commit script file. No hook by default.
  • Optional fallback-version: The fallback version, if no older one can be detected, or if it is the first one. Default '0.1.0'
  • Optional config-file-path: Path to the conventional changelog config file. If set, the preset setting will be ignored
  • Optional pre-changelog-generation: Path to the pre-changelog-generation script file. No hook by default.

Pre-Commit hook

Function in a specified file will be run right before the git-add-git-commit phase, when the next version is already known and a new changelog has been generated. You can run any chores across your repository that should be added and commited with the release commit.

Specified path could be relative or absolute. If it is relative, then it will be based on the GITHUB_WORKSPACE path.

Script should:

  • be a CommonJS module
  • have a single export: exports.preCommit = (props) => { /* ... */ }
  • not have any return value
  • be bundled (contain all dependencies in itself, just like the bundled webapp)

preCommit function can be async.

Following props will be passed to the function as a single parameter:

interface Props {
  tag: string; // Next tag e.g. v1.12.3
  version: string; // Next version e.g. 1.12.3
}

export function preCommit(props: Props): void {}

A bunch of useful environment variables are available to the script with process.env. See docs.github.com/en/actions/configuring-and-managing-workflows/using-environment-variables to learn more.

Pre-Changelog-Generation hook

Function in a specified file will be run right before the changelog generation phase, when the next version is already known, but it was not used anywhere yet. It can be useful if you want to manually update version or tag.

Same restrictions as for the pre-commit hook, but exported functions names should be preVersionGeneration for modifications to the version and preTagGeneration for modifications to the git tag.

Following props will be passed to the function as a single parameter and same output is expected:

// Next version e.g. 1.12.3
export function preVersionGeneration(version: string): string {}

// Next tag e.g. v1.12.3
export function preTagGeneration(tag: string): string {}

Config-File-Path

A config file to define the conventional commit settings. Use it if you need to override values like issuePrefix or issueUrlFormat. If you set a config-file-path, the preset setting will be ignored. Therefore use an existing config and override the values you want to adjust.

example:

'use strict'
const config = require('conventional-changelog-conventionalcommits');

module.exports = config({
    "issuePrefixes": ["TN-"],
    "issueUrlFormat": "https://jira.example.com/browse/{{prefix}}{{id}}"
})

The specified path can be relative or absolute. If it is relative, then it will be based on the GITHUB_WORKSPACE path.

Make sure to install all required packages in the workflow before executing this action.

Outputs

  • changelog: The generated changelog for the new version.
  • clean_changelog: The generated changelog for the new version without the version name in it (Better for Github releases)
  • version: The new version.
  • tag: The name of the generated tag.
  • skipped: Boolean ('true' or 'false') specifying if this step have been skipped

Example usages

Uses all the defaults

- name: Conventional Changelog Action
  uses: TriPSs/conventional-changelog-action@v3
  with:
    github-token: ${{ secrets.github_token }}

Overwrite everything

- name: Conventional Changelog Action
  uses: TriPSs/conventional-changelog-action@v3
  with:
    github-token: ${{ secrets.github_token }}
    git-message: 'chore(release): {version}'
    git-user-name: 'Awesome Changelog Action'
    git-user-email: 'awesome_changelog@github.actions.com'
    preset: 'angular'
    tag-prefix: 'v'
    output-file: 'MY_CUSTOM_CHANGELOG.md'
    release-count: '10'
    version-file: './my_custom_version_file.json' // or .yml, .yaml, .toml
    version-path: 'path.to.version'
    skip-on-empty: 'false'
    skip-version-file: 'false'
    skip-commit: 'false'

No file changelog

- name: Conventional Changelog Action
  uses: TriPSs/conventional-changelog-action@v3
  with:
    github-token: ${{ secrets.github_token }}
    output-file: "false"

Tag only

- name: Conventional Changelog Action
  uses: TriPSs/conventional-changelog-action@v3
  with:
    github-token: ${{ secrets.github_token }}
    skip-commit: "true"

Use a custom file for versioning

- name: Conventional Changelog Action
  uses: TriPSs/conventional-changelog-action@v3
  with:
    github-token: ${{ secrets.github_token }}
    version-file: "my-custom-file.yaml"

Use a pre-commit hook

- name: Conventional Changelog Action
  uses: TriPSs/conventional-changelog-action@v3
  with:
    github-token: ${{ secrets.github_token }}
    pre-commit: some/path/pre-commit.js

Github releases

- name: Conventional Changelog Action
  id: changelog
  uses: TriPSs/conventional-changelog-action@v3
  with:
    github-token: ${{ secrets.github_token }}
    output-file: "false"

- name: Create Release
  uses: actions/create-release@v1
  if: ${{ steps.changelog.outputs.skipped == 'false' }}
  env:
    GITHUB_TOKEN: ${{ secrets.github_token }}
  with:
    tag_name: ${{ steps.changelog.outputs.tag }}
    release_name: ${{ steps.changelog.outputs.tag }}
    body: ${{ steps.changelog.outputs.clean_changelog }}

Use a deploy key

- name: Checkout GitHub Action
  uses: actions/checkout@v2
  with:
    ssh-key: ${{ secrets.SSH_DEPLOY_KEY }}
- name: Conventional Changelog Action
  id: changelog
  uses: TriPSs/conventional-changelog-action@v3

Development

If you'd like to contribute to this project, all you need to do is clone and install act this project and run:

Make sure that main: 'src/index.js' is updated to main: '../src/index.js' inside the action.yml Note: The image used is 18 gb!

$ yarn install

# To run / test json versioning
$ act -j test-json -P ubuntu-latest=nektos/act-environments-ubuntu:18.04 -s github_token=fake-token

# To run / test git versioning
$ act -j test-git -P ubuntu-latest=nektos/act-environments-ubuntu:18.04 -s github_token=fake-token

# To run / test git fallback versioning
$ act -j test-git-fallback -P ubuntu-latest=nektos/act-environments-ubuntu:18.04 -s github_token=fake-token

# To run / test yaml versioning
$ act -j test-yaml -P ubuntu-latest=nektos/act-environments-ubuntu:18.04 -s github_token=fake-token

# To run / test toml versioning
$ act -j test-toml -P ubuntu-latest=nektos/act-environments-ubuntu:18.04 -s github_token=fake-token

# To run / test empty / new files test
$ act -j test-[json/toml/yaml]-[empty/new] -P ubuntu-latest=nektos/act-environments-ubuntu:18.04 -s github_token=fake-token

# To run pre-commit test
$ act -j test-pre-commit -P ubuntu-latest=nektos/act-environments-ubuntu:18.04 -s github_token=fake-token

# To run / multiple files test
$ act -j multiple-files -P ubuntu-latest=nektos/act-environments-ubuntu:18.04 -s github_token=fake-token

# To run / config file path test
$ act -j test-config-file-path -P ubuntu-latest=nektos/act-environments-ubuntu:18.04 -s github_token=fake-token

# To run pre-changelog-generation test
$ act -j test-pre-changelog-generation -P ubuntu-latest=nektos/act-environments-ubuntu:18.04 -s github_token=fake-token

Collaboration

If you have questions or issues, please open an issue!

Download Details:

Author: TriPSs
Source Code: https://github.com/TriPSs/conventional-changelog-action 
License: MIT license

#javascript #action #github 

Conventional Changelog Action
Hunter  Krajcik

Hunter Krajcik

1661172600

Action Handler: Simple Way to Decouple Actions From View

Action Handler

Simple way to decouple actions from View.

Actions

An action is everything that can interact with the user, but it's not a state.

Example 1: Navigate to another Page after some backend operation. The backend result should not be placed inside the button onPressed (because it's not its responsibility to deal with it), so it's safe to assume that this is an action.

Example 2: Show a non blocking error (dialog) after some operation. If it's necessary to show a dialog after some non blocking error, this logic should not me placed inside the button onPressed method, so this is probably an action too.

How to use it

There're 2 (two) available widgets: ActionHandler and ValueListenableActionHandler.

The first one uses Streams, the second one uses ValueNotifier. Once your Widget is completed, you MUST dispose the Stream/ValueNotifier.

ActionHandler<int>(
    actionInput: _controller.onStreamEvent,
    actionResult: (result) {
      print('Stream: $result \n');
    },
    child: Scaffold(
       appBar: AppBar(
         title: Text('Action Handler Demo'),
       ),
       body: Center(
         child: Text(
           'Push the button',
         ),
       ),
       floatingActionButton: FloatingActionButton(
         onPressed: _controller.increaseQuantity,
         tooltip: 'Increment',
         child: Icon(Icons.add),
       ),
     ),
   ),
  );

Use this package as a library

Depend on it

Run this command:

With Flutter:

 $ flutter pub add action_handler

This will add a line like this to your package's pubspec.yaml (and run an implicit flutter pub get):

dependencies:
  action_handler: ^1.0.1+2

Alternatively, your editor might support flutter pub get. Check the docs for your editor to learn more.

Import it

Now in your Dart code, you can use:

import 'package:action_handler/action_handler.dart';

example/lib/main.dart

import 'package:action_handler/action_handler.dart';
import 'package:action_handler/value_listenable_action_handler.dart';
import 'package:example/main_controller.dart';
import 'package:flutter/material.dart';

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) => MaterialApp(
        title: 'Flutter Demo',
        theme: ThemeData(
          primarySwatch: Colors.blue,
        ),
        home: MyHomePage(
          controller: MainController(),
        ),
      );
}

class MyHomePage extends StatefulWidget {
  MyHomePage({
    required this.controller,
    Key? key,
  }) : super(key: key);

  final MainController controller;

  @override
  State<StatefulWidget> createState() => _MyHomePageState();

}

class _MyHomePageState extends State<MyHomePage> {
  MainController get _controller => widget.controller;

  @override
  Widget build(BuildContext context) => ActionHandler<int>(
    actionInput: _controller.onStreamEvent,
    actionResult: (result) {
      print('Stream: $result \n');
    },
    child: ValueListenableActionHandler(
      actionInput: _controller.onNotifierEvent,
      actionResult: (result) {
        print('ValueNotifier: $result \n');
      },
      child: Scaffold(
        appBar: AppBar(
          title: Text('Action Handler Demo'),
        ),
        body: Center(
          child: Text(
            'Push the button',
          ),
        ),
        floatingActionButton: FloatingActionButton(
          onPressed: _controller.increaseQuantity,
          tooltip: 'Increment',
          child: Icon(Icons.add),
        ),
      ),
    ),
  );

  @override
  void dispose() {
    _controller.dispose();
    super.dispose();
  }
}

Download Details:

Author: mobyleOfficial
Source Code: https://github.com/mobyleOfficial/action_handler 
License: MIT license

#flutter #dart #action 

Action Handler: Simple Way to Decouple Actions From View
Dexter  Goodwin

Dexter Goodwin

1660407300

Semantic-release-action: GitHub Action for Running Semantic-release

semantic-release-action

GitHub Action for running semantic-release. Respects any semantic-release configuration file in your repo or the release prop in your package.json. Exports environment variables for you to use in subsequent actions containing version numbers.

Usage

See action.yml.

Referencing the major version is (recommended by GitHub).

steps:
  # Reference the major version of a release
  - uses: codfish/semantic-release-action@v2
  # Reference a specific commit
  - uses: codfish/semantic-release-action@c4074285a1651e4fecab9c14974d5e01b4625edf
  # Reference a minor version of a release
  - uses: codfish/semantic-release-action@v1.10
  # Reference a branch
  - uses: codfish/semantic-release-action@master

Note: Whenever you use a custom docker-based GitHub Action like this one, you may notice in your run logs, one of the first steps you'll see will be GA building the image for you. You can speed up runs by pulling pre-built docker images instead of making GitHub Actions build them on every run.

steps:
  # Reference a docker image from GitHub Container Registry
  - uses: docker://ghcr.io/codfish/semantic-release-action:v2
  # Reference a docker image from Dockerhub
  - uses: docker://codfish/semantic-release-action:v2

If you're security conscious, you can pin the docker image down to a specific digest instead of using an image tag, which is a mutable reference.

steps:
  # Reference a docker image from GitHub Container Registry (example for v2.0.0)
  - uses: docker://ghcr.io/codfish/semantic-release-action@sha256:91ea452696d93a34a30aff20b34614b75e8fddc82b598fc8fa57c3ac07e6d6da

Inspect the image version you want here to find the digest. If you prefer pulling from Docker Hub, check here.

Basic Usage

steps:
  - uses: actions/checkout@v2

  - uses: codfish/semantic-release-action@v2
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

Using output variables set by semantic-release-action:

steps:
  - uses: actions/checkout@v2

  # you'll need to add an `id` in order to access output variables
  - uses: codfish/semantic-release-action@v2
    id: semantic
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

  - run: echo ${{ steps.semantic.outputs.release-version }}

  - run: echo "$OUTPUTS"
    env:
      OUTPUTS: ${{ toJson(steps.semantic.outputs) }}

  - uses: codfish/some-other-action@v1
    with:
      release-version: ${{ steps.semantic.outputs.release-version }}

Example: Only run an action if a new version was created.

steps:
  - uses: actions/checkout@v2

  # you'll need to add an `id` in order to access output variables
  - uses: codfish/semantic-release-action@v2
    id: semantic
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

  - name: docker push version
    if: steps.semantic.outputs.new-release-published == 'true'
    run: |
      docker tag some-image some-image:$TAG
      docker push some-image:$TAG
    env:
      TAG: v$RELEASE_VERSION

Using environment variables set by semantic-release-action:

steps:
  - uses: actions/checkout@v2

  - uses: codfish/semantic-release-action@v2
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

  - run: |
      echo $RELEASE_VERSION
      echo $RELEASE_MAJOR
      echo $RELEASE_MINOR
      echo $RELEASE_PATCH

If you're not publishing to npm and only want to use this action for GitHub releases, the easiest approach would simply be to add "private": true, to your package.json.

Why

It's fairly easy to run semantic-release as a "host action," aka something that runs directly on the VM.

steps:
  - run: npx semantic-release
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

If you're just publishing a node package, then this could still work well for you. The problem I found with this is when I was in projects where I had subsequent steps/actions in which I wanted to know whether a new version was cut.

Use Case: For instance, in an application where I'm using semantic-release to manage GitHub releases, but also building and pushing docker images. Dockerhub has a nice GitHub integration to handle this for us, but some other registries do not. If I need to cut a new release, then update a docker registry by adding a new tagged build, I'll want to run semantic-release and then build a docker image, tag it with a version and push it up. In my case I like to push up tags for latest, the semver (i.e. v1.8.3), and just the major the version (i.e. v1).

I want to know 1) if semantic-release cut a new version and 2) what the version is.

There's a number of ways to handle this, but the most elegant way I found to do it was to abstract it into it's own custom action. It abstracts away whatever logic you need to figure out what that new release number is.

This also scales well, just in case I want to add some flexibility and functionality to this action, I can easily leverage it across any project.

Configuration

You can pass in semantic-release configuration options via GitHub Action inputs using with.

It's important to note, NONE of these inputs are required. Semantic release has a default configuration that it will use if you don't provide any.

Also of note, if you'd like to override the default configuration and you'd rather not use the inputs here, the action will automatically use any semantic-release configuration defined in your repo (.releaserc, release.config.js, release prop in package.json)

Note: Each input will take precedence over options configured in the configuration file and shareable configurations.

Input VariableTypeDescription
branchesArray, String, ObjectThe branches on which releases should happen.
pluginsArrayDefine the list of plugins to use. Plugins will run in series, in the order defined, for each steps if they implement it
extendsArray, StringList of modules or file paths containing a shareable configuration.
additional_packagesArray, StringDefine a list of additional plugins/configurations (official or community) to install. Use this if you 1) use any plugins other than the defaults, which are already installed along with semantic-release or 2) want to extend from a shareable configuration.
dry_runBooleanThe objective of the dry-run mode is to get a preview of the pending release. Dry-run mode skips the following steps: prepare, publish, success and fail.
repository_urlStringThe git repository URL
tag_formatStringThe Git tag format used by semantic-release to identify releases.

Note: Any package specified in extends or additional_packages will be installed automatically for you as a convenience, allowing you to use this action without adding new dependencies to your application or install deps in a separate action step.

Note: additional_packages won't get used automatically, setting this variable will just install them so you can use them. You'll need to actually list them in your plugins and/or extends configuration for semantic-release to use them.

Note: The branch input is DEPRECATED. Will continue to be supported for v1. Use branches instead. Previously used in semantic-release v15 to set a single branch on which releases should happen.

Example with all inputs

steps:
  - run: codfish/semantic-release-action@v2
    with:
      dry_run: true
      branches: |
        [
          '+([0-9])?(.{+([0-9]),x}).x',
          'master',
          'next',
          'next-major',
          {
            name: 'beta',
            prerelease: true
          },
          {
            name: 'alpha',
            prerelease: true
          }
        ]
      repository_url: https://github.com/codfish/semantic-release-action.git
      tag_format: 'v${version}'
      extends: '@semantic-release/apm-config'
      additional_packages: |
        ['@semantic-release/apm@4.0.0', '@semantic-release/git']
      plugins: |
        ['@semantic-release/commit-analyzer', '@semantic-release/release-notes-generator', '@semantic-release/github', '@semantic-release/apm', '@semantic-release/git']
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

Outputs

semantic-release-action sets both output variables and environment variables because why not? Allows users the ability to use whichever they want. I don't know or understand every use case there might be so this is a way to cover more cases.

Docs: https://help.github.com/en/articles/metadata-syntax-for-github-actions#outputs

Output Variables:

Output VariableDescription
new-release-publishedEither 'true' when a new release was published or 'false' when no release was published. Allows other actions to run or not-run based on this
release-versionThe new releases' semantic version, i.e. 1.8.3
release-majorThe new releases' major version number, i.e. 1
release-minorThe new releases' minor version number, i.e. 8
release-patchThe new releases' patch version number, i.e. 3
release-notesThe release notes of the next release.

Environment Variables:

Environment VariableDescription
NEW_RELEASE_PUBLISHEDEither 'true' when a new release was published or 'false' when no release was published. Allows other actions to run or not-run based on this
RELEASE_VERSIONThe new releases' semantic version, i.e. 1.8.3
RELEASE_MAJORThe new releases' major version number, i.e. 1
RELEASE_MINORThe new releases' minor version number, i.e. 8
RELEASE_PATCHThe new releases' patch version number, i.e. 3
RELEASE_NOTESThe release notes of the next release in markdown.

Maintenance

Make the new release available to those binding to the major version tag: Move the major version tag (v1, v2, etc.) to point to the ref of the current release. This will act as the stable release for that major version. You should keep this tag updated to the most recent stable minor/patch release.

git tag -fa v2 -m "Update v2 tag" && git push origin v2 --force

Reference: https://github.com/actions/toolkit/blob/master/docs/action-versioning.md recommendations

Download Details:

Author: Codfish
Source Code: https://github.com/codfish/semantic-release-action 
License: MIT license

#javascript #github #action 

Semantic-release-action: GitHub Action for Running Semantic-release
Reid  Rohan

Reid Rohan

1660101000

Setup GitHub Actions Workflow with A Specific Version Of Bun

action-setup-bun

Setup GitHub Actions workflow with a specific version of Bun and add $BUN_INSTALL/bin to the $PATH.

Requirements

  • macOS x64 & Silicon, Linux x64, Windows Subsystem for Linux

Usage

- name: Setup Bun Runtime
  uses: antongolub/action-setup-bun@v1 # or @v1.x.x
  with:
    # Optional, if empty the latest bun version will be used
    # Examples: 0.0.77, 0.1.2, >=0.1, *
    bun-version: 0.1.2

    # Optional, default is 'Jarred-Sumner/bun-releases-for-updater'
    # Example: oven-sh/misc-test-builds
    bun-repo: 'Jarred-Sumner/bun-releases-for-updater'

    # Override bunfig.toml inners
    # Optional. JSON-formatted string as input
    # See: https://github.com/oven-sh/bun#bunfigtoml
    bun-config: '{"install: {"production": false}}'
    
    # Attach $BUN_INSTALL/install/cache to action/cache
    # Optional, defaults to false
    cache: true

    # actions/tool-cache provides a cache for the current job only
    # Use actions/cache to store the bun binary for the whole workflow
    # Optional, defaults to false
    cache-bin: true

    # Optional, default is process.platform
    # Examples: darwin, linux
    platform: 'linux'

    # Optional, default is process.arch
    # Examples: x64, arm64
    arch: 'x64'
    
    # Authenticated requests get a higher rate limit
    # Optional. Defaults to ${{ github.token }}
    token: 'gh-token'

- name: Run script
  run: bun index.js

bun-repo

There are at least 3 known places to fetch bun distributions:

$HOME

The env.HOME is used to store the bun binary (${HOME}/.bun/bin). If you want to assign another directory, you can override this env option.

env:
  HOME: '/custom/path'

Outputs

NameDescription
bun-versionThe version of Bun that was installed
cache-hitif the bun cache was hit: true / false
errorif an error occurred, the error message

Debug

This flag can be enabled by setting the secret ACTIONS_STEP_DEBUG to true.

Download Details:

Author: Antongolub
Source Code: https://github.com/antongolub/action-setup-bun 
License: MIT license

#typescript #setup #action #github 

Setup GitHub Actions Workflow with A Specific Version Of Bun
Hunter  Krajcik

Hunter Krajcik

1659555840

Q_action: QAction, Easier anction with A Question

QAction is a simple package that lets you write an action link that comes after a question. You can use it to Navigate to a new screen or to a website or whatever you want.

Features

String question; String actionName; Color questionColor; Color actionNameColor; Function action; TextStyle questionStyle; TextStyle actionNameStyle; double fontSize;

Getting started

import 'package:q_action/q_action.dart';

Usage

<%@include file="example/lib/main.dart"%>

Installing

Use this package as a library

Depend on it

Run this command:

With Flutter:

 $ flutter pub add q_action

This will add a line like this to your package's pubspec.yaml (and run an implicit flutter pub get):

dependencies:
  q_action: ^0.0.1

Alternatively, your editor might support flutter pub get. Check the docs for your editor to learn more.

Import it

Now in your Dart code, you can use:

import 'package:q_action/q_action.dart';

example/lib/main.dart

import 'package:example/example.dart';
import 'package:flutter/material.dart';
import 'package:q_action/q_action.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return Material(
      child: QAction(
        question: "Want learn more?",
        actionName: "Click Here",
        action: () {
          Navigator.push(
            context,
            MaterialPageRoute(
              builder: (context) => const Example(),
            ),
          );
        },
      ),
    );
  }
}

Author: Veasnawt
Source Code: https://github.com/veasnawt/q_action 
License: View license

#flutter #dart #action 

Q_action: QAction, Easier anction with A Question
Brook  Hudson

Brook Hudson

1659210780

Commander: The Complete Solution for Ruby Command-line Executables

 Commander

The complete solution for Ruby command-line executables. Commander bridges the gap between other terminal related libraries you know and love (OptionParser, HighLine), while providing many new features, and an elegant API.

Features

  • Easier than baking cookies
  • Parses options using OptionParser
  • Auto-populates struct with options ( no more { |v| options[:recursive] = v } )
  • Auto-generates help documentation via pluggable help formatters
  • Optional default command when none is present
  • Global / Command level options
  • Packaged with two help formatters (Terminal, TerminalCompact)
  • Imports the highline gem for interacting with the terminal
  • Adds additional user interaction functionality
  • Highly customizable progress bar with intuitive, simple usage
  • Multi-word command name support such as drupal module install MOD, rather than drupal module_install MOD
  • Sexy paging for long bodies of text
  • Support for MacOS text-to-speech
  • Command aliasing (very powerful, as both switches and arguments can be used)
  • Growl notification support for MacOS
  • Use the commander executable to initialize a commander driven program

Installation

$ gem install commander

Quick Start

To generate a quick template for a commander app, run:

$ commander init yourfile.rb

To generate a quick modular style template for a commander app, run:

$ commander init --modular yourfile.rb

Example

For more option examples view the Commander::Command#option method. Also an important feature to note is that action may be a class to instantiate, as well as an object, specifying a method to call, so view the RDoc for more information.

Classic style

require 'rubygems'
require 'commander/import'

# :name is optional, otherwise uses the basename of this executable
program :name, 'Foo Bar'
program :version, '1.0.0'
program :description, 'Stupid command that prints foo or bar.'

command :foo do |c|
  c.syntax = 'foobar foo'
  c.description = 'Displays foo'
  c.action do |args, options|
    say 'foo'
  end
end

command :bar do |c|
  c.syntax = 'foobar bar [options]'
  c.description = 'Display bar with optional prefix and suffix'
  c.option '--prefix STRING', String, 'Adds a prefix to bar'
  c.option '--suffix STRING', String, 'Adds a suffix to bar'
  c.action do |args, options|
    options.default :prefix => '(', :suffix => ')'
    say "#{options.prefix}bar#{options.suffix}"
  end
end

Example output:

$ foobar bar
# => (bar)

$ foobar bar --suffix '}' --prefix '{'
# => {bar}

Modular style

NOTE: Make sure to use require 'commander' rather than require 'commander/import', otherwise Commander methods will still be imported into the global namespace.

require 'rubygems'
require 'commander'

class MyApplication
  include Commander::Methods

  def run
    program :name, 'Foo Bar'
    program :version, '1.0.0'
    program :description, 'Stupid command that prints foo or bar.'

    command :foo do |c|
      c.syntax = 'foobar foo'
      c.description = 'Displays foo'
      c.action do |args, options|
        say 'foo'
      end
    end

    run!
  end
end

MyApplication.new.run if $0 == __FILE__

Block style

require 'rubygems'
require 'commander'

Commander.configure do
  program :name, 'Foo Bar'
  program :version, '1.0.0'
  program :description, 'Stupid command that prints foo or bar.'

  # see classic style example for options
end

HighLine

As mentioned above, the highline gem is imported into the global scope. Here are some quick examples for how to utilize highline in your commands:

# Ask for password masked with '*' character
ask("Password:  ") { |q| q.echo = "*" }

# Ask for password
ask("Password:  ") { |q| q.echo = false }

# Ask if the user agrees (yes or no)
agree("Do something?")

# Asks on a single line (note the space after ':')
ask("Name: ")

# Asks with new line after "Description:"
ask("Description:")

# Calls Date#parse to parse the date string passed
ask("Birthday? ", Date)

# Ensures Integer is within the range specified
ask("Age? ", Integer) { |q| q.in = 0..105 }

# Asks for a list of strings, converts to array
ask("Fav colors?", Array)

HighLine & Interaction Additions

In addition to highline's fantastic choice of methods, commander adds the following methods to simplify common tasks:

# Ask for password
password

# Ask for password with specific message and mask character
password "Enter your password please:", '-'

# Ask for CLASS, which may be any valid class responding to #parse. Date, Time, Array, etc
names = ask_for_array 'Names: '
bday = ask_for_date 'Birthday?: '

# Simple progress bar (Commander::UI::ProgressBar)
uris = %w[
  http://vision-media.ca
  http://google.com
  http://yahoo.com
]
progress uris do |uri|
  res = open uri
  # Do something with response
end

# 'Log' action to stdout
log "create", "path/to/file.rb"

# Enable paging of output after this point
enable_paging

# Ask editor for input (EDITOR environment variable or whichever is available: TextMate, vim, vi, emacs, nano, pico)
ask_editor

# Ask editor, supplying initial text
ask_editor 'previous data to update'

# Ask editor, preferring a specific editor
ask_editor 'previous data', 'vim'

# Choose from an array of elements
choice = choose("Favorite language?", :ruby, :perl, :js)

# Alter IO for the duration of the block
io new_input, new_output do
  new_input_contents = $stdin.read
  puts new_input_contents # outputs to new_output stream
end
# $stdin / $stdout reset back to original streams

# Speech synthesis
speak 'What is your favorite food? '
food = ask 'favorite food?: '
speak "Wow, I like #{food} too. We have so much in common."
speak "I like #{food} as well!", "Victoria", 190

# Execute arbitrary applescript
applescript 'foo'

# Converse with speech recognition server
case converse 'What is the best food?', :cookies => 'Cookies', :unknown => 'Nothing'
when :cookies
  speak 'o.m.g. you are awesome!'
else
  case converse 'That is lame, shall I convince you cookies are the best?', :yes => 'Ok', :no => 'No', :maybe => 'Maybe another time'
  when :yes
    speak 'Well you see, cookies are just fantastic, they melt in your mouth.'
  else
    speak 'Ok then, bye.'
  end
end

Growl Notifications

Commander provides methods for displaying Growl notifications. To use these methods you need to install https://github.com/tj/growl which utilizes the growlnotify executable. Note that growl is auto-imported by Commander when available, no need to require.

# Display a generic Growl notification
notify 'Something happened'

# Display an 'info' status notification
notify_info 'You have #{emails.length} new email(s)'

# Display an 'ok' status notification
notify_ok 'Gems updated'

# Display a 'warning' status notification
notify_warning '1 gem failed installation'

# Display an 'error' status notification
notify_error "Gem #{name} failed"

Commander Goodies

Option Defaults

The options struct passed to #action provides a #default method, allowing you to set defaults in a clean manner for options which have not been set.

command :foo do |c|
  c.option '--interval SECONDS', Integer, 'Interval in seconds'
  c.option '--timeout SECONDS', Integer, 'Timeout in seconds'
  c.action do |args, options|
    options.default \
      :interval => 2,
      :timeout  => 60
  end
end

Command Aliasing

Aliases can be created using the #alias_command method like below:

command :'install gem' do |c|
  c.action { puts 'foo' }
end
alias_command :'gem install', :'install gem'

Or more complicated aliases can be made, passing any arguments as if it was invoked via the command line:

command :'install gem' do |c|
  c.syntax = 'install gem <name> [options]'
  c.option '--dest DIR', String, 'Destination directory'
  c.action { |args, options| puts "installing #{args.first} to #{options.dest}" }
end
alias_command :update, :'install gem', 'rubygems', '--dest', 'some_path'
$ foo update
# => installing rubygems to some_path

Command Defaults

Although working with a command executable framework provides many benefits over a single command implementation, sometimes you still want the ability to create a terse syntax for your command. With that in mind we may use #default_command to help with this. Considering our previous :'install gem' example:

default_command :update
$ foo
# => installing rubygems to some_path

Keeping in mind that commander searches for the longest possible match when considering a command, so if you were to pass arguments to foo like below, expecting them to be passed to :update, this would be incorrect, and would end up calling :'install gem', so be careful that the users do not need to use command names within the arguments.

$ foo install gem
# => installing  to

Long descriptions

If you need to have a long command description, keep your short description under summary, and consider multi-line strings for description:

  program :summary, 'Stupid command that prints foo or bar.'
  program :description, %q(
#{c.summary}

More information about that stupid command that prints foo or bar.

And more
  )

Additional Global Help

Arbitrary help can be added using the following #program symbol:

program :help, 'Author', 'TJ Holowaychuk <tj@vision-media.ca>'

Which will output the rest of the help doc, along with:

AUTHOR:

  TJ Holowaychuk <tj@vision-media.ca>

Global Options

Although most switches will be at the command level, several are available by default at the global level, such as --version, and --help. Using #global_option you can add additional global options:

global_option('-c', '--config FILE', 'Load config data for your commands to use') { |file| ... }

This method accepts the same syntax as Commander::Command#option so check it out for documentation.

All global options regardless of providing a block are accessable at the command level. This means that instead of the following:

global_option('--verbose') { $verbose = true }
...
c.action do |args, options|
  say 'foo' if $verbose
...

You may:

global_option '--verbose'
...
c.action do |args, options|
  say 'foo' if options.verbose
...

Formatters

Two core formatters are currently available, the default Terminal formatter as well as TerminalCompact. To utilize a different formatter simply use :help_formatter like below:

program :help_formatter, Commander::HelpFormatter::TerminalCompact

Or utilize the help formatter aliases:

program :help_formatter, :compact

This abstraction could be utilized to generate HTML documentation for your executable.

Tracing

By default the -t and --trace global options are provided to allow users to get a backtrace to aid debugging.

You can disable these options:

never_trace!

Or make it always on:

always_trace!

Tips

When adding a global or command option, OptionParser implicitly adds a small switch even when not explicitly created, for example -c will be the same as --config in both examples, however -c will only appear in the documentation when explicitly assigning it.

global_option '-c', '--config FILE'
global_option '--config FILE'

ASCII Tables

For feature rich ASCII tables for your terminal app check out the terminal-table gem at https://github.com/tj/terminal-table

+----------+-------+----+--------+-----------------------+
| Terminal | Table | Is | Wicked | Awesome               |
+----------+-------+----+--------+-----------------------+
|          |       |    |        | get it while its hot! |
+----------+-------+----+--------+-----------------------+

Running Specifications

$ rake spec

OR

$ spec --color spec

Contrib

Feel free to fork and request a pull, or submit a ticket https://github.com/commander-rb/commander/issues

License

This project is available under the MIT license. See LICENSE for details.


Author: commander-rb
Source code: https://github.com/commander-rb/commander
License: MIT license

#ruby  #ruby-on-rails 

Commander: The Complete Solution for Ruby Command-line Executables
Royce  Reinger

Royce Reinger

1658899080

MediaWiki API: A Library for interacting with MediaWiki API From Ruby

MediaWiki API

A library for interacting with MediaWiki API from Ruby. Uses adapter-agnostic Faraday gem to talk to the API.

Installation

Add this line to your application's Gemfile:

gem "mediawiki_api"

And then execute:

$ bundle

Or install it yourself as:

$ gem install mediawiki_api

Usage

Assuming you have MediaWiki installed via MediaWiki-Vagrant.

require "mediawiki_api"

client = MediawikiApi::Client.new "http://127.0.0.1:8080/w/api.php"
client.log_in "username", "password" # default Vagrant username and password are "Admin", "vagrant"
client.create_account "username", "password" # will not work on wikis that require CAPTCHA, like Wikipedia
client.create_page "title", "content"
client.get_wikitext "title"
client.protect_page "title", "reason", "protections" #  protections are optional, default is "edit=sysop|move=sysop"
client.delete_page "title", "reason"
client.upload_image "filename", "path", "comment", "ignorewarnings"
client.watch_page "title"
client.unwatch_page "title"
client.meta :siteinfo, siprop: "extensions"
client.prop :info, titles: "Some page"
client.query titles: ["Some page", "Some other page"]

Advanced Usage

Any API action can be requested using #action. See the MediaWiki API documentation for supported actions and parameters.

By default, the client will attempt to get a csrf token before attempting the action. For actions that do not require a token, you can specify token_type: false to avoid requesting the unnecessary token before the real request. For example:

client.action :parse, page: 'Main Page', token_type: false

Links

MediaWiki API gem at: Gerrit, GitHub, RubyGems, Code Climate.

Contributing

See https://www.mediawiki.org/wiki/Gerrit

Release notes

0.7.1 2017-01-31

  • Add text param to MediawikiApi::Client#upload_image

0.7.0 2016-08-03

  • Automatically follow redirects for all API requests.

0.6.0 2016-05-25

  • Update account creation code for AuthManager. This change updates the gem to test which API flavor is in use, then send requests accordingly.

0.5.0 2015-09-04

  • Client cookies can now be read and modified via MediawikiApi::Client#cookies.
  • Logging in will recurse upon a NeedToken API error only once to avoid infinite recursion in cases where authentication is repeatedly unsuccessful.

0.4.1 2015-06-17

  • Allow for response-less ApiError exceptions to make mocking in tests easier

0.4.0 2015-06-16

  • Use action=query&meta=tokens to fetch tokens, instead of deprecated action=tokens

0.3.1 2015-01-06

  • Actions now automatically refresh token and re-submit action if first attempt returns 'badtoken'.

0.3.0 2014-10-14

  • HTTP 400 and 500 responses now result in an HttpError exception.
  • Edit failures now result in an EditError exception.

0.2.1 2014-08-26

  • Fix error handling for token requests

0.2.0 2014-08-06

  • Automatic response parsing.
  • Handling of API error responses.
  • Watch/unwatch support.
  • Query support.
  • Public MediawikiApi::Client#action method for advanced API use.

0.1.4 2014-07-18

  • Added MediawikiApi::Client#protect_page.
  • Updated documentation.

0.1.3 2014-06-28

  • Added MediawikiApi::Client#upload_image.

0.1.2 2014-04-11

  • Added MediawikiApi::Client#get_wikitext.

0.1.1 2014-04-01

  • Updated documentation.

0.1.0 2014-03-13

  • Complete refactoring.
  • Removed MediawikiApi#create_article, #create_user and #delete_article.
  • Added MediawikiApi::Client#new, #log_in, #create_page, #delete_page, #create_account.
  • Added unit tests.

0.0.2 2014-02-11

  • Added MediawikiApi#delete_article.

0.0.1 2014-02-07

  • Added MediawikiApi#create_article and #create_user.

Author: Wikimedia
Source Code: https://github.com/wikimedia/mediawiki-ruby-api 
License: View license

#ruby #api #media 

MediaWiki API: A Library for interacting with MediaWiki API From Ruby

How to Create an Action Figure Using Adobe Photoshop CC

In this tutorial, I will teach you how to create an Action figure using Adobe Photoshop CC.

Please subscribe to my channel!

Contact Details:
hello@raddy.co.uk

Website:
www.raddy.co.uk

Blog:
www.raddy.co.uk/blog

Sound Effects:
Shadie Carrier - www.scdesign.co.uk

Music:
Vibe With Me by Joakim Karud http://soundcloud.com/joakimkarud Music promoted by Audio Library https://youtu.be/-7YDBIGCXsY

#adobe photoshop cc #create an action figure #action

How to Create an Action Figure  Using Adobe Photoshop CC

RAZA KHAN

1625422758

Action Movie .. one of the BEST MOVIE

https://dailyuploads.net/n7iuhnlfs2r9

#https://dailyuploads.net/n7iuhnlfs2r9 #action #movies

Action Movie .. one of the BEST MOVIE
Ian  Robinson

Ian Robinson

1624422240

Actionable Insights Steer Industries Towards Better Business Decisions

In the current digital world, there is no industry that won’t benefit from actionable insights. With time, every industry will adapt to it. For example, in financial technology, a problem that requires actionable insights is credit risk assessment. A well-structured fintech algorithm can easily use machine learning to suggest to employees whether they can approve and reject a loan application. That advice is actionable insight.

The algorithm assesses the applicant’s probability of load success by training on heaps of historical data and market conditions. The result of the algorithm is the insightful judgment of the applicant’s acceptable or unacceptable risk. Action, in this case, is the human loan agent’s decision to grant the loan or deny it. The majority of businesses in today’s day and age depend on such insights. They require actionable insights incorporated in the workflows to drive better business outcomes without people having to leave their primary tasks to sieve through data for answers.

#big data #data analytics #action #decision to #actionable insights #actionable insights steer industries towards better business decisions

Actionable Insights Steer Industries Towards Better Business Decisions

Do GitHub Action like a Pro!

A set of development practices you wish you’d known before publishing your first Action.

#devops #do #github #action #pro

Do GitHub Action like a Pro!