Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

initial fuzzit orb version #1

Merged
merged 5 commits into from Nov 10, 2019
Merged
Changes from all commits
Commits
File filter...
Filter file types
Jump to…
Jump to file
Failed to load files.

Always

Just for now

@@ -1,24 +1,123 @@
version: 2.1

# add your orb below, to be used in integration tests (note: a @dev:alpha
# release must exist; you'll need to publish manually at least once)
# you can use scripts/publish-alpha.sh to publish a @dev:alpha release
orbs:
fuzzit: fuzzitdev/fuzzit@dev:alpha
orb-tools: circleci/orb-tools@8.27.3
shellcheck: circleci/shellcheck@1.3.14

jobs:
getting-started:
docker:
- image: circleci/node
steps:
- run:
name: Getting Started
command: |
echo "Your orb is now building on CircleCI"
echo "This is a temporary configuration file. Continue with the orb-init.sh script and follow the README.md to publish your orb."

workflows:
setup:
# this `lint-pack_validate_publish-dev` workflow will run on any commit
lint-pack_validate_publish-dev:
jobs:
- getting-started
# lint your destructured orb YAML files
- orb-tools/lint
- shellcheck/check:
ignore: 'SC1090,SC2034,SC2059,SC2001,SC2143,SC2046'

# pack your orb YAML files to a single orb.yml
# validate the orb.yml file to ensure it is well-formed
- orb-tools/pack:
requires:
- orb-tools/lint

# release dev version of orb, for testing & possible publishing
# requires a CircleCI API token to be stored as CIRCLE_TOKEN (default)
# https://circleci.com/docs/2.0/managing-api-tokens
# store CIRCLE_TOKEN as a project env var or Contexts resource
# if using Contexts, add your context below
- orb-tools/publish-dev:
orb-name: fuzzitdev/fuzzit
requires:
- orb-tools/pack

# trigger an integration workflow to test the dev version of your orb
# an SSH key must be stored in your orb's repository and in CircleCI
# (add the public key as a read/write key on GitHub; add the private
# key in CircleCI via SSH Permissions, with github.com as Hostname)
- orb-tools/trigger-integration-workflow:
name: trigger-integration-dev
ssh-fingerprints: 28:e3:ab:d2:77:42:9e:c5:12:76:a6:8c:46:af:5e:c7
requires:
- orb-tools/publish-dev
filters:
branches:
ignore: master

# by default, the 1st job (above) will trigger only integration tests;
# the 2nd job (below) may also publish a production orb version
- orb-tools/trigger-integration-workflow:
name: trigger-integration-master
cleanup-tags: true
ssh-fingerprints: 28:e3:ab:d2:77:42:9e:c5:12:76:a6:8c:46:af:5e:c7
tag: master
requires:
- orb-tools/publish-dev
filters:
branches:
only: master

# this `integration-tests_prod-release` workflow will ignore commits
# it is only triggered by git tags, which are created in the job above
# integration-tests_prod-release:
# jobs:
# # - your integration test jobs go here
# # - you will want to call each integration testing job twice,
# # - each under a different name:
# # - once, for integration tests triggered by non-master-branch commits
# # - and again, for tests triggered by commits to master
# # - only commits to master should potentially trigger a prod release

# # patch, minor, or major publishing
# - orb-tools/dev-promote-prod:
# name: dev-promote-patch
# orb-name: circleci/orb-tools
# ssh-fingerprints: # your SSH key fingerprint
# cleanup-tags: true
# requires:
# # - your integration testing jobs go here
# filters:
# branches:
# ignore: /.*/
# tags:
# only: /master-patch.*/

# - orb-tools/dev-promote-prod:
# name: dev-promote-minor
# release: minor
# orb-name: circleci/orb-tools
# ssh-fingerprints: # your SSH key fingerprint
# cleanup-tags: true
# requires:
# # - your integration testing jobs go here
# filters:
# branches:
# ignore: /.*/
# tags:
# only: /master-minor.*/

# - orb-tools/dev-promote-prod:
# name: dev-promote-major
# release: major
# orb-name: circleci/orb-tools
# ssh-fingerprints: # your SSH key fingerprint
# cleanup-tags: true
# requires:
# # - your integration testing jobs go here
# filters:
# branches:
# ignore: /.*/
# tags:
# only: /master-major.*/

# yaml anchor filters
integration-dev_filters: &integration-dev_filters
branches:
ignore: /.*/
tags:
only: /integration-.*/

integration-master_filters: &integration-master_filters
branches:
ignore: /.*/
tags:
only: /master-.*/
@@ -0,0 +1 @@
.idea
169 README.md
@@ -1,148 +1,49 @@
# Orb Starter Kit [![CircleCI Build Status](https://circleci.com/gh/CircleCI-Public/orb-starter-kit.svg?style=shield "CircleCI Build Status")](https://circleci.com/gh/CircleCI-Public/orb-starter-kit) [![CircleCI Community](https://img.shields.io/badge/community-CircleCI%20Discuss-343434.svg)](https://discuss.circleci.com/c/ecosystem/orbs)
# Fuzzit Orb for CircleCI

This orb starter kit will help you write your own orb.
## What is Fuzzit Orb

Orbs are reusable [commands](https://circleci.com/docs/2.0/reusing-config/#authoring-reusable-commands), [executors](https://circleci.com/docs/2.0/reusing-config/#authoring-reusable-executors), and [jobs](https://circleci.com/docs/2.0/reusing-config/#jobs-defined-in-an-orb) (as well as [usage examples](https://github.com/CircleCI-Public/config-preview-sdk/blob/v2.1/docs/usage-examples.md))—snippets of CircleCI configuration—that can be shared across teams and projects. See [CircleCI Orbs](https://circleci.com/orbs), [Explore Orbs](https://circleci.com/orbs/registry), [Creating Orbs](https://circleci.com/docs/2.0/creating-orbs), and [Using Orbs](https://circleci.com/docs/2.0/using-orbs) for further information.

## What is in this kit?

In this Orb-Starter-Kit you will find an automated setup to create a development pipeline to build your orb automatically. Once setup is complete you will have a functioning hello-world orb that is automatically built and released on each commit. Commits to the `master` branch will trigger production Orb releases and other branches will create development versions of your Orb for testing.

### Prerequisites

Before getting started you will need the the following things:
1. A CircleCI [account](https://circleci.com/signup/).
2. Git installed and configured locally.
3. A CircleCI [Personal API Token](https://circleci.com/docs/2.0/managing-api-tokens/#creating-a-personal-api-token) (Must be Org admin to claim a namespace and publish production Orbs)
4. A GitHub [Personal Access Token](https://help.github.com/en/articles/creating-a-personal-access-token-for-the-command-line) (Requires Repo access and Admin Org if pushing to an Org that is not your personal account)
This orb helps integrate continuous fuzzing via Fuzzit.dev to your CircleCI workflow.

This orb provides 3 main features: downloading latest version fo fuzzit cli, running fuzzing
on fuzzit.dev and running local fuzzing regression.

## Usage

### Getting started
1. Download this repository and unzip it. [Download here](https://github.com/CircleCI-Public/orb-starter-kit/archive/master.zip)

2. Rename the folder to the name you would like to give your orb.

3. Run the `orb-init.sh` script to begin.
> The Orb Init script will automate the following tasks:
> * Install and update the CircleCI CLI
> * Request a CircleCI API token if none is currently set.
> * Set the target GitHub organization.
> * Set the target repo name (based off the folder name by default).
> * Create the GitHub repository.
> * Follow the project on CircleCI
> * Create a public/private key pair.
> * Store public key on GitHub.
> * Store private key on CircleCI (This gives the starter kit the ability to push tags back to GitHub, currently utilized to automatically trigger integration testing and deployment workflows).
> * Delete these keys locally.
> * Create an Alpha branch
> * Modify and replace config.yml file with pre-configured Orb Starter Kit config.
> * Commit new branch with changes to GitHub.
> * Clean up - The script will remove itself from the repo for the next commit.
>
> At this point the script will provide you a link to your new running Workflow on CircleCI which will be automatically building a "hello world" orb, which will be available at `<your namespace>/<your orb>@dev:Alpha`
4. Begin editing.
> Once the script has finished you may edit the contents of the /src folder to customize your orb.
5. Create your dev Orb!
> All commits to non-master branches will automatically result in the creation of a development orb under that branch. It is recommended currently (changes incoming) all changes be made under the automatically created Alpha branch.
6. Publish!
> Merge to master and automatically publish a new production version of your Orb!
>
> You will need to manually publish the production version of your Orb the first time it is created. This is not needed on subsequent pushes. *NOTE* currently _all_ 'major' changes as defined by the Orbs-Tool Orb require manual publishing. All minor and patch changes will be automatically published.
Once the orb is complete, you will have two new Green workflows in your CircleCI account. The first one is for the initial setup and the second one will have produced a development version of your orb which contains a sample Command, Executor, and Job.

You may now simply modify these examples and add your own. Any new commit to the repo automatically trigger a development pipeline

#### What happens when I push a commit?

The Orb CI/CD pipeline begins! Your Orb will go through the `lint-pack_validate_publish-dev` workflow. The code will first be linted, then passed to the "pack" job which will take your multiple partial yaml files and condense them into a single Orb.yml file, lastly, if specified within the `config.yml`, and defined integration tests will also be ran.

Based on the branch you push to, the workflow will automatically create a development version of your orb for any branch except for "Master" which will create a production release which will be automatically incremented.

### Writing your orb
This orb provides a basic directory/file structure for a decomposed orb (where commands, jobs, examples, and executors each live in their own YAML file). Create each of your commands, jobs, examples, and executors within the requisite folders in the `src` directory.

Following are some resources to help you build and test your orb:
#### Download only

- [Tips for writing your first orb](https://circleci.com/blog/tips-for-writing-your-first-orb/)
- [How to make an easy and valuable open source contribution with CircleCI orbs](https://circleci.com/blog/how-to-make-an-easy-and-valuable-open-source-contribution-with-circleci-orbs/)
- Creating automated build, test, and deploy workflows for orbs: [part 1](https://circleci.com/blog/creating-automated-build-test-and-deploy-workflows-for-orbs/), [part 2](https://circleci.com/blog/creating-automated-build-test-and-deploy-workflows-for-orbs-part-2/)

### Permissions

Explanation of all permissions required for the script.

* **sudo** - The CircleCI CLI Update command will request sudo permissions to update.
* **GitHub personal access token** - Used to automatically create the repository for you. Will require full "repo" access.
* **SSH keys** - A public key is added to the repo on GitHub, CircleCI will hold the private key. This is used to automatically create tagged commits from within the Workflow to enable integration testing.
```yaml
version: 2.1
orbs:
fuzzit: fuzzitdev/fuzzit@x.y.z
jobs:
build:
docker:
- image: circleci/golang:1.12
working_directory: /go/src/github.com/fuzzitdev/example-go
<details>
<Summary>Preview "Hello-World" Orb produced by this repo by default.</Summary>
steps:
- checkout
- fuzzit/download
- run: ./fuzzit.sh fuzzing
```

#### Download + fuzzing/local-regression
```yaml
commands:
greet:
description: |
Replace this text with a description for this command. # What will this command do? # Descriptions should be short, simple, and clear.
parameters:
greeting:
default: Hello
description: Select a proper greeting
type: string
steps:
- run:
command: echo << parameters.greeting >> world
name: Hello World
description: |
Sample orb description # What will your orb allow users to do? # Descriptions should be short, simple, and clear.
examples:
example:
description: |
Sample example description. # What will this example document? # Descriptions should be short, simple, and clear.
usage:
jobs:
build:
machine: true
steps:
- foo/hello:
username: Anna
orbs:
foo: bar/foo@1.2.3
version: 2.1
executors:
default:
description: |
This is a sample executor using Docker and Node. # What is this executor? # Descriptions should be short, simple, and clear.
version: 2.1
orbs:
fuzzit: fuzzitdev/fuzzit@x.y.z
jobs:
build:
docker:
- image: circleci/node:<<parameters.tag>>
parameters:
tag:
default: latest
description: |
Pick a specific circleci/node image variant: https://hub.docker.com/r/circleci/node/tags
type: string
jobs:
hello:
description: |
# What will this job do? # Descriptions should be short, simple, and clear.
executor: default
parameters:
greeting:
default: Hello
description: Select a proper greeting
type: string
- image: circleci/golang:1.12
working_directory: /go/src/github.com/fuzzitdev/example-go
steps:
- greet:
greeting: << parameters.greeting >>
orbs:
hello: circleci/hello-build@0.0.5
version: 2.1
- checkout
- fuzzit/fuzzing # or local-regression, this will call the fuzzit.sh script
```

</details>
#### Additional parameters

`FUZZIT_API_KEY` should be passed. More info about the fuzzit CLI can be found at
[https://github.com/fuzzitdev/fuzzit](https://github.com/fuzzitdev/fuzzit)

This file was deleted.

This file was deleted.

ProTip! Use n and p to navigate between commits in a pull request.
You can’t perform that action at this time.