GithubHelp home page GithubHelp logo

go-vela / community Goto Github PK

View Code? Open in Web Editor NEW
22.0 18.0 3.0 1022 KB

Community Information for Vela (Target's official Pipeline Automation Framework)

Home Page: https://go-vela.github.io/docs/

License: Apache License 2.0

Dockerfile 6.36% Makefile 36.36% Go 54.95% Shell 2.32%
community documentation issues stories

community's Introduction

Vela Community

A collection of documentation that is designed to provide information about the product to the broader community!

Copyright

All source code and documentation is governed by Target's copyright infringement policies.

Copyright (c) 2022 Target Brands, Inc.

Migrations

A collection of documentation and utilities to ease the transition between releases for Vela.

Please see our migrations documentation documentation for more information.

Proposals

A collection of potential new features or modifications to be made to the product.

Please see our proposals documentation documentation for more information.

Releases

A collection of records (a.k.a. release notes) detailing the new features or modifications made to the product.

Please see our releases documentation documentation for more information.

License

Vela is an open source product licensed under version 2.0 of the Apache License.

community's People

Contributors

chrispdriscoll avatar dependabot[bot] avatar ecrupper avatar jbrockopp avatar jordansussman avatar kaymckay avatar keisukeyamashita avatar kellymerrick avatar matt-fevold avatar plyr4 avatar renovate[bot] avatar timhuynh94 avatar tmapes avatar wass3r avatar wass3rw3rk avatar

Stargazers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Watchers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Forkers

keisukeyamashita jordansussman jbrockopp

community's Issues

Add comment event to builds page event filter

Description

Currently the filter on the builds page doesn't account for comment events.

Value

Allow users to filter by all currently supported events.

Definition of Done

User is able to filter builds by selecting "comment" in the filter control.

Effort (Optional)

Impacted Personas (Optional)

Add a note about case-sensitivity

Description

Add some well-placed notes about the importance of making sure to use case-sensitive values (matching SCM conventions), eg. if the organization is MyOrg, use the same case-sensitive version in your CLI commands.

Value

  • Increase clarity of whether values should be case-sensitive

Definition of Done

  • Notes added to clarify case-sensitivity

Effort (Optional)

Impacted Personas (Optional)

Builds page filter does not filter by deployment correctly

Description

filter changes url to <baseurl>/<org>/<repo>?event=deploy instead of <baseurl>/<org>/<repo>?event=deployment. also adjust filter name from deploy to deployment.

Value

users are able to filter deployment events appropriately

Useful Information

  1. What is the output of vela --version?
  1. What operating system is being used?
  1. Any other important details?

vela-s3-cache restore issue with symbolic links

Description

Original story: go-vela/vela-s3-cache#11

for applications using npm or yarn that want to cache their dependencies (ie. node_modules folder), the restored cache resolves symlinks incorrectly.

example restored cache items:

$ ls -la node_modules/.bin
total 16
drwxr-xr-x 2 root root 4096 Apr 14 19:33 .
drwxr-xr-x 313 root root 12288 Apr 14 19:33 ..
lrwxrwxrwx 1 root root 23 Apr 14 19:33 acorn -> node_modules/.bin/acorn
lrwxrwxrwx 1 root root 22 Apr 14 19:33 atob -> node_modules/.bin/atob
lrwxrwxrwx 1 root root 23 Apr 14 19:33 errno -> node_modules/.bin/errno
lrwxrwxrwx 1 root root 38 Apr 14 19:33 import-local-fixture -> node_modules/.bin/import-local-fixture
lrwxrwxrwx 1 root root 23 Apr 14 19:33 json5 -> node_modules/.bin/json5
lrwxrwxrwx 1 root root 30 Apr 14 19:33 miller-rabin -> node_modules/.bin/miller-rabin
lrwxrwxrwx 1 root root 24 Apr 14 19:33 mkdirp -> node_modules/.bin/mkdirp
lrwxrwxrwx 1 root root 24 Apr 14 19:33 rimraf -> node_modules/.bin/rimraf
lrwxrwxrwx 1 root root 24 Apr 14 19:33 semver -> node_modules/.bin/semver
lrwxrwxrwx 1 root root 24 Apr 14 19:33 sha.js -> node_modules/.bin/sha.js
lrwxrwxrwx 1 root root 24 Apr 14 19:33 terser -> node_modules/.bin/terser
lrwxrwxrwx 1 root root 25 Apr 14 19:33 webpack -> node_modules/.bin/webpack
lrwxrwxrwx 1 root root 29 Apr 14 19:33 webpack-cli -> node_modules/.bin/webpack-cli
lrwxrwxrwx 1 root root 23 Apr 14 19:33 which -> node_modules/.bin/which

expected output should be:

$ ls -la node_modules/.bin
total 16
drwxr-xr-x 2 root root 4096 Apr 14 19:34 .
drwxr-xr-x 313 root root 12288 Apr 14 19:34 ..
lrwxrwxrwx 1 root root 18 Apr 14 19:34 acorn -> ../acorn/bin/acorn
lrwxrwxrwx 1 root root 19 Apr 14 19:34 atob -> ../atob/bin/atob.js
lrwxrwxrwx 1 root root 15 Apr 14 19:34 errno -> ../errno/cli.js
lrwxrwxrwx 1 root root 31 Apr 14 19:34 import-local-fixture -> ../import-local/fixtures/cli.js
lrwxrwxrwx 1 root root 19 Apr 14 19:34 json5 -> ../json5/lib/cli.js
lrwxrwxrwx 1 root root 32 Apr 14 19:34 miller-rabin -> ../miller-rabin/bin/miller-rabin
lrwxrwxrwx 1 root root 20 Apr 14 19:34 mkdirp -> ../mkdirp/bin/cmd.js
lrwxrwxrwx 1 root root 16 Apr 14 19:34 rimraf -> ../rimraf/bin.js
lrwxrwxrwx 1 root root 20 Apr 14 19:34 semver -> ../semver/bin/semver
lrwxrwxrwx 1 root root 16 Apr 14 19:34 sha.js -> ../sha.js/bin.js
lrwxrwxrwx 1 root root 20 Apr 14 19:34 terser -> ../terser/bin/terser
lrwxrwxrwx 1 root root 25 Apr 14 19:34 webpack -> ../webpack/bin/webpack.js
lrwxrwxrwx 1 root root 25 Apr 14 19:34 webpack-cli -> ../webpack-cli/bin/cli.js
lrwxrwxrwx 1 root root 18 Apr 14 19:34 which -> ../which/bin/which

potentially related to this: mholt/archiver#202

Value

Useful Information

  1. What is the output of vela --version?
  1. What operating system is being used?
  1. Any other important details?

Expose PR branch as environment variable

Description

Original story: go-vela/server#127

In a pull request event, BUILD_BRANCH is populated with the name of the base branch that the PR is targeting, but it would be nice to have access to the pull request branch name as well.

Value

Definition of Done

A user can successfully reference the original PR branch name in a pipeline.

Effort (Optional)

1 day

Impacted Personas (Optional)

users

Support for build artifact storage and post-build access

Description

Original story: go-vela/.github#3

Many testing tools and frameworks like Cypress, JUnit, Spock, etc...can generates screenshots or small video clips that capture the steps leading to the runtime error. How can developers access that info on CI Server?

Value

It helped pin point the root cause of failure during integration or end-2-end testing. Having the exact reproducible steps with visual assistance allows developers troubleshoot and fix the bug faster.

Definition of Done

Users can navigate, view or download the artifacts for each build.

Effort (Optional)

N/A

Impacted Personas (Optional)

users

Get/View hooks for CLI

Description

Original story: go-vela/cli#52

Implement hooks management via the Vela CLI

Value

Offer the same functionality presented in the UI at /org/repo/hooks but via the CLI.

eg.

vela get hooks --org octocat --repo hello-world
vela view hook --org octocat --repo hello-world --hook-number 10

Definition of Done

A user can view hooks through the CLI

Effort (Optional)

2 days

Impacted Personas (Optional)

users

Allow greater fidelity of ruleset matching

Description

Original story: go-vela/types#70

Current ruleset matching utilizes a file match pattern utility. This does not allow for more stringent matching, particularly with version tags. Use regex pattern matching since it allows for greater control and it commonly known.

Value

Allows more control over step ruleset matchers

Definition of Done

Current ruleset must have one or more exclude clause to eliminate greedy matches for tags with trailing data. e.g. -SNAPSHOT, -rc, -prod, etc.

    ruleset:
      if:
        event: [ tag ]
        tag: [ "[0-9].*" ]
      unless:
        event: [ tag ]
        tag: [ "[0-9].*-prod" ]

After enhancement regex can be used to explicitly identify start/end of match

if:
  branch: master
  event: tag
  tag: [ "^refs/tags/(\\d+\\.)+\\d+$" ]

Effort (Optional)

4 days

Impacted Personas (Optional)

users

Additional secret engines for Vault

Description

Original story: go-vela/server#77

I purpose that vela should support more secret engines besides key/value, like gcp, aws, and azure. This change could easily allow administrators to provide a set of credentials to be utilized by tools like terraform without needing to provide long lived credentials.

Some specific design considerations to think of:

  • Multiple values are returned by the secret engines mentioned above
    • for example, secret_key, secret_token, lease_duration, etc.
  • Should the secret be configured within vault directly or via vela?
    • configuring through vela can be challenging for specific secret engines/configurations due to the number of steps for setup
  • Vela specific metadata about these secrets cannot be stored within vault since it doesn't allow additonal metadata like the k/v secret engine does

My initial thought on changes to the pipeline to accomplish this looks like:

version: "1"

steps:
- name: test
  image: alpine
  secrets: [ aws ]
  commands:
    - env | grep AWS_

secrets:
  - name: aws
    key:  aws/sts/foo
    engine: vault
    ttl: 60m

With the step of test returning the output of:

AWS_LEASE_ID=<value>
AWS_LEASE_DURATION=<value>
AWS_LEASE_RENEWABLE=<value>
AWS_ACCESS_KEY=<value>
AWS_SECRET_KEY=<value>
AWS_SECURITY_TOKEN=<value>

The above example showcases that vela will retrieve the credentials through the aws secrets engine and convert all of the returned values to be in the format of <secret name in vela.yml>_<key returned in vault>=<key value>.

My proposed workflow to accomplish the above looks like:

  1. Vault administrator enables the new secret engine of AWS within Vault
    • i.e. vault secrets enable aws and vault write aws/config/root access_key=<access key> secret_key=<secret key> region=<region>
  2. Vault administrator writes the role(s) they want
    • i.e. vault write aws/roles/<role name> credential_type=<credential type> ...
  3. Vela administrator maps the Vault secret with a Vela secret
    • i.e. vela map secret <name of secret within vault> --name <name of secret within vela> --org <org> --repo <repo> ...
  4. Vela stores the above metadata about the secret within the Vela database since Vault doesn't allow that type of metadata for non k/v store secret engines
  5. User attempts to utilize the newly mapped secret with a pipeline
  6. Vela connects to Vault to receive the credentials if the validation to approve injection was successful
  7. Vela injects the secrets into the pipeline

Looking for feedback on this before I attempt to write the code to accomplish it.

Value

Definition of Done

Effort (Optional)

1 week

Impacted Personas (Optional)

Vault users

Explain where to get token

Description

Original story: go-vela/docs#135

wass3r commented 19 days ago

Consider enumerating the different methods to retrieve the token to use in API calls and add them to: https://go-vela.github.io/docs/api/authentication/

Value

Make it clear where a user can retrieve their user token

Definition of Done

Documentation has been added to explain where a user can find their token.

Effort (Optional)

1 day

Impacted Personas (Optional)

users

Build sdk-python

Description

Original story: go-vela/sdk-python#1

Build a Software Development Kit (SDK) for the Python language.

Value

  • Enable Python developers to integrate with the Vela system
  • Decrease barrier to entry for Python developers to create custom integrations

Definition of Done

The SDK is implemented and usable inside a Python application.

Effort (Optional)

1 week

Impacted Personas (Optional)

users who prefer Python

Add content for templates in vela-tutorials

Description

Original story: go-vela/vela-tutorials#2

Add content for the templates section.

Value

Decrease barrier to entry with templates
Increase clarity around intended use-cases for templates
Create a guide for other organizations to create their own templates

Definition of Done

The tutorials section of this repository contains content.

Effort (Optional)

2 days

Impacted Personas (Optional)

users who use templates

Allow local pipeline execution

Description

Enable the ability to execute a Vela pipeline on a local workstation

Value

  • provide another mechanism to troubleshoot Vela pipelines
  • reduce dependency on Vela services being available to execute pipelines
  • maintain feature parity with existing CI solutions

Definition of Done

A Vela pipeline can be ran on a local workstation

Effort (Optional)

2 weeks

Impacted Personas (Optional)

everyone

Provide a build event stream

Description

Original story: go-vela/server#88

Provide a consumable stream of events generated from build activity.

Value

Enable third party services and integrations

Definition of Done

A stream of events in relation to build activity can be consumed.

Effort (Optional)

2 weeks

Impacted Personas (Optional)

users

Respond to Github PR Reactions

Description

Original story: go-vela/server#111

Respond to PR Reactions to trigger builds

Value

Support more diverse workflows

Definition of Done

A user can successfully trigger a build via a PR reaction on GitHub.

Effort (Optional)

1 week

Impacted Personas (Optional)

users

add CLI pagination documentation

Description

Original story: go-vela/docs#105

Add information on how to paginate through multi-page results with the CLI

Value

To let users know that there's a way to get to further results

Definition of Done

Information about the pagination parameters is added to the docs

Effort (Optional)

1 day

Impacted Personas (Optional)

users

Secret docs missing --page and --per-page

Description

Original story: go-vela/docs#119

galacticgumshoe commented on Apr 7

I had noticed that older secrets were no longer appearing on my list when doing vela get secret --org data-engineering-fieldops --type org --repo '*'. After posting this to #vela on Slack, I came to learn about two flags which are not documented. These do allow me to view secrets beyond my initial page, so should be added to the documentation https://go-vela.github.io/docs/cli/secret/:

--page
--per-page

Value

To let users know that there's a way to get to further results

Definition of Done

Information about the pagination parameters is added to the docs

Effort (Optional)

1 day

Impacted Personas (Optional)

users

vela-artifactory doesn't fail the pipeline on errors

Description

Original story: go-vela/vela-artifactory#44

[Error] [Thread 2] Artifactory response: 409 Conflict
[Error] Failed uploading 1 artifacts.

this example output would still leave the step it was used on as a successful step

Value

Useful Information

  1. What is the output of vela --version?
  1. What operating system is being used?
  1. Any other important details?

expand semver tags for auto_tag feature in vela-docker

Description

Original issue: go-vela/vela-docker#35

Currently, auto_tag, when applied during a tag event, will simply tag the container with BUILD_TAG, but it would be nice if it would create a series of tags based on the tag provided, if it is recognized as a semantic version number.

Example: If BUILD_TAG is v2.1.24, the following tags would be created (the "v", if present, will be stripped):

  • 2.1.24
  • 2.1
  • 2
  • latest

Value

This will allow container users to "subscribe" to a particular version scope, depending on their comfort level, and receive updates without knowing exact patch numbers, for example.

Definition of Done

The auto_tag parameter should cause tagging to behave as described above.

Effort (Optional)

1 day

Impacted Personas (Optional)

users of vela-docker

Improve test coverage for vela-git

Description

Original story: go-vela/vela-git#32

Improve test coverage to > 90% for go-vela/vela-git

NOTE: This includes nested packages!

Value

  • reduce technical debt
  • decrease potential for bugs

Definition of Done

The plugin and all nested pkgs have > 90% test coverage

Effort (Optional)

2 days

Impacted Personas (Optional)

users

Colorize log output

Description

Original story: go-vela/ui#141

Log output that contains ANSI control sequence to colorize text is unhandled resulting in them being rendered as-is. Let's convert them and treat affected output respectively.

Value

Cleaner log output

Definition of Done

Control characters/escape sequences are converted to respective color. In addition, colors are accessible for currently supported themes.

Effort (Optional)

2 days

Impacted Personas (Optional)

Log output viewers

View services on build page for a repo

Description

Original story: go-vela/ui#94

Add ability to see services used in pipeline, including their log output.

Value

Enhance the experience of visually tying the user's pipeline to what the user has defined it to be.

Definition of Done

User is able to see what services were created in their pipeline and is able to view their respective logs.

Effort (Optional)

1 week

Impacted Personas (Optional)

users

Enable removal of deleted repositories

Description

Original story: go-vela/server#95

If a repo is deleted from git, it will still appear in Vela and cannot be removed. Please allow repositories that have been deleted from git to be removed from vela.

Value

The current workaround is to recreate the repo, remove from vela, and re-delete. These added steps cost time.

Definition of Done

If a git repo no longer exists, a user will still be able to remove them

Effort (Optional)

1 day

Impacted Personas (Optional)

users

JWT expiration & refresh token

Description

Original story: go-vela/server#134

Note: This change will be taking place in multiple places/repos - other stories to follow.

Currently, JWT returned by the server lives indefinitely. The client is responsible for retiring it. This change will introduce expiration for the JWT to make it short-lived and introduce a long-lived refresh token.

Value

Improved security

Definition of Done

  • Server returns JWT + Refresh Token with expiration.
  • Provides means to retrieve new JWT via refresh token endpoint.
  • Expired JWT, Refresh Token prevents access.

Effort (Optional)

2 weeks

Impacted Personas (Optional)

users

Limit concurrency of builds (Rate limit builds)

Description

Original story: go-vela/server#123

Enable the ability to limit the concurrent running vela pipelines for a given repository and/or given branches within the repository.

Some extra thoughts needed for considerations:

  • should the setting be defined within the .vela.yml and/or settings page of the UI?
  • should builds be queued if the limit is reached or have the webhook return some error?

Value

This is primarily helpful for repositories that are implementing deployments, and having multiple run at the same time can cause unintended behavior.

Definition of Done

Users are able to define the concurrency of running vela pipelines within the API.

Effort (Optional)

1 week

Impacted Personas (Optional)

users

Support include and exclude patterns for path ruleset

Description

Original story: go-vela/types#65

Update the ruleset to allow include and exclude logic for the path element.

Design

Both of the below proposed design changes to the .vela.yml would have the same underlying results of:

  • Commit that changes cool-code/foo.js will trigger
  • Commit that changes cool-code/docs/foo.md will not trigger

proposed option 1

Add ignore and include underneath path to allow the following configuration:

ruleset:
  path: 
    include:
      - [ "cool-code/**" ]
    exclude:
      - [ "cool-code/docs/**"]

This could lead to breaking behavior due to the current structure of the yaml so extra consideration is needed.

proposed option 2

Utilize some ignore character(s) to allow updating the existing path to handle both scenarios. The following example utilizes the ignore character of !:

ruleset:
  path: [ "!cool-code/docs/**", "cool-code/** ]

Value

Greatly simplifies scenarios where you want to exclude a specific file(s) or folder(s), and not need to call out includes for everything else.

Definition of Done

ruleset for path updated to allow include and exclude logic

Effort (Optional)

1 day

Impacted Personas (Optional)

All users utilizing the path element of ruleset

Install - Please Don't Place Exe's In C:\Windows\System32

Description

Original story: go-vela/docs#131

mikebeckel commented 23 days ago

Please don't place EXE's in C:\Windows\System32. It's a OS folder and while it makes it easy to make your executable accessible as it's included in the System Path it's not the correct approach for several reasons.

  • It obfuscates the origin of your executable and can be interpreted as malware.
  • It requires that users have Administrative rights to modify

The best approach is to create an installer so that it can be installed to Program Files. The next best approach is for the user to place in into a directory of their choosing, such as their user profile, and update the User Path so that it's accessible from anywhere for that user.

Value

  • clarify location of executable
  • reduce potential for executable to be interpreted as malware
  • enable users who don't have local admin rights

Definition of Done

A better location for installing the Windows executable is provided in the documentation

Effort (Optional)

1 day

Impacted Personas (Optional)

users

Add Open Api (swagger) Spec to workers

Description

The worker api should be documented.

Value

This will make interacting with the api easier, especially for server <-> worker communication

Definition of Done

There is a spec for the workers in the worker repo.

Effort (Optional)

Couple days

Respond to Github Label events

Description

Original story: go-vela/server#110

Respond to Label events to trigger builds

Value

Support more diverse workflows

Definition of Done

A user can successfully trigger a build via a label on GitHub.

Effort (Optional)

1 week

Impacted Personas (Optional)

users

Server needs to proxy worker endpoints to manage builds

Description

Original story: go-vela/server#86

Provide a mechanism for users to manage (cancel/kill) a running build

Value

Terminate a long running (potentially rogue?) process
Prevent a misconfigured build from harming the system(s) it interacts with

Definition of Done

A user can send an API call to the server that will handle the communication with the worker to manage the build.

Effort (Optional)

2 weeks

Impacted Personas (Optional)

users

Create JSON Schema to utilize with code editors

Description

Original story: go-vela/types#67

Create a JSON schema to allow code editors to parse the .vela.yml and help users understand if the format is valid or not.

The simple steps to test the JSON schema:

  1. convert complex .vela.yml from yaml to json
  2. utilize https://jsonschema.net/home to create JSON schema
  3. follow editor specific instructions to utilize the schema for .vela.yml

Value

Definition of Done

Users able to configure code editor to utilize published JSON schema for file validation

Effort (Optional)

2 days

Impacted Personas (Optional)

All users modifying .vela.yml within any code editor

View stages on build page for a repo

Description

Original story: go-vela/ui#95

Add ability to see stages used in pipeline, including their log output.

Value

Enhance the experience of visually tying the user's pipeline to what the user has defined it to be.

Definition of Done

User is able to see what stages were created in their pipeline and is able to view their respective logs.

Effort (Optional)

1 week

Impacted Personas (Optional)

users

Manage favorited repos for CLI

Description

Original story: go-vela/cli#53

Implement repo favorites management via the Vela CLI

Value

Offer the same functionality presented in the UI at / (home page) but via the CLI.

eg.

vela get favorites or update functionality for vela get repos
vela add favorite --org octocat --repo hello-world

Definition of Done

A user can manage favorites through the CLI

Effort (Optional)

2 days

Impacted Personas (Optional)

users

Respond to Github PR comment events

Description

Original story: go-vela/server#112

Respond to more PR comment events to trigger builds

  • pull request review comments
  • pull request reviews

Value

Support more diverse workflows

Definition of Done

A user can successfully trigger a build via a PR comment on GitHub.

Effort (Optional)

1 week

Impacted Personas (Optional)

users

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.