Git Product home page Git Product logo

fabric8-wit's Introduction

Fabric8 Work Item Tracker

Jenkins Go Report Card GoDoc Codecov.io

Work Items describe and keep track of work that needs to be done. A user can be assigned to a Work Item. Each Work Item must be attached to a Collaboration Space and an Area (assigned by default). This can be used to model bugs, tasks, features, ideas, and more.

1. Building from source

The following guide is mainly targeted towards a Linux or Mac OSX development machine. If you are on Windows, we recommend to take a look at Getting started with fabric8-wit development on Windows.

1.1. Prerequisites

You need to install:

  • go (>= v1.8)

  • git

  • mercurial

  • make

1.1.1. Check your Go version

Run the following command to find out your Go version.

$ go version

You must at least have Go version 1.8.

See Fetch dependencies to see an explanaition on how we deal with dependencies.

1.1.2. Install dep

This project uses dep as a package manager for Go. Running the make deps command will install dep in $GOPATH/bin if it’s not already available on your system.

1.2. Get the code

Assuming you have Go installed and configured (have $GOPATH setup and pointing to a single directory) here is how to build.

Check out the code

$ git clone https://github.com/fabric8-services/fabric8-wit $GOPATH/src/github.com/fabric8-services/fabric8-wit

1.3. Build

Like most other projects, this one depends on various other projects that need to be downloaded.

We also generate some code from design files that shall make it into our final artifacts.

To fetch the dependencies, generate code and finally build the project you can type make in a freshly clone repository of this project.

$ cd $GOPATH/src/github.com/fabric8-services/fabric8-wit
$ make

1.3.1. Special make targets

There is no need to fetch the dependencies, or re-generate code every time you want to compile. That’s why we offer special make targets for these topics:

Fetch dependencies

This will download all the dependencies for this project inside a directory called vendor. This way we can ensure that every developer and our CI system is using the same version.

$ cd $GOPATH/src/github.com/fabric8-services/fabric8-wit
$ make deps

For dependency management of go packages we use dep. The file Gopkg.toml contains all dependencies. If you want to understand the format for this file, look here.

Generate GOA sources

You need to run this command if you just checked out the code and later if you’ve modified the designs.

$ cd $GOPATH/src/github.com/fabric8-services/fabric8-wit
$ make generate
Build

If you want to just build the ALM server and client, run make build.

$ cd $GOPATH/src/github.com/fabric8-services/fabric8-wit
$ make build
Clean

This removes all downloaded dependencies, all generated code and compiled artifacts.

$ cd $GOPATH/src/github.com/fabric8-services/fabric8-wit
$ make clean
Tests

Here’s how to run all available tests. All tests will check all Go packages except those in the vendor/ directory. Make sure you have docker and docker-compose available.

Setting up test environment - make integration-test-env-prepare

Tear test environment down - make integration-test-env-tear-down

unit-tests

Unit tests have the minimum requirement on time and environment setup.

$ cd $GOPATH/src/github.com/fabric8-services/fabric8-wit
$ make test-unit
integration-tests

Integration tests demand more setup (i.e. the PostgreSQL DB must be already running) and probably time. We recommend that you use docker-compose up -d db.

$ cd $GOPATH/src/github.com/fabric8-services/fabric8-wit
$ make test-integration
all

To run both, the unit and the integration tests you can run

$ cd $GOPATH/src/github.com/fabric8-services/fabric8-wit
$ make test-all
Coverage

To visualize the coverage of unit, integration, or all tests you can run these commands:

  • $ make coverage-unit

  • $ make coverage-integration

  • $ make coverage-all

Note
If the tests (see Tests) have not yet run, or if the sources have changed since the last time the tests ran, they will be re-run to produce up to date coverage profiles.

Each of the above tests (see Tests) produces a coverage profile by default. Those coverage files are available under

tmp/coverage/<package>/coverage.<test>.mode-<mode>

Here’s how the <placeholders> expand

<package>

something like github.com/fabric8-services/fabric8-wit/models

<test>

unit or integration

<mode>

Sets the mode for coverage analysis for the packages being tested. Possible values for <mode> are set (the default), count, or atomic and they directly relate to the output of go test --help.

  • set: bool: does this statement run?

  • count: int: how many times does this statement run?

  • atomic: int: count, but correct in multithreaded tests; significantly more expensive.

In addition to all individual coverage information for each package, we also create three more files:

tmp/coverage.unit.mode-<mode>

This file collects all the coverage profiles for all unit tests.

tmp/coverage.integration.mode-<mode>

This file collects all the coverage profiles for all integration tests.

tmp/coverage.mode-<mode>

This file is the merge result of the two afore mentioned files and thus gives coverage information for all tests.

2. Build through minishift

There is a separate documentation for building WIT using minishift

3. Configuration file

If no configuration file is specified when the core is started, these are the defaults.

config.yaml
#------------------------
# Postgres configuration
#------------------------

postgres.host: localhost
postgres.port: 5432
postgres.user: postgres
postgres.password: mysecretpassword
postgres.database: postgres
postgres.sslmode: disable
# The amount of time in seconds before the connection times out
postgres.connection.timeout: 5
# Duration to wait before trying to connect again
postgres.connection.retrysleep: 1s

#------------------------
# HTTP configuration
#------------------------

http.address: 0.0.0.0:8080

#------------------------
# Misc.
#------------------------

# Enable development related features, e.g. token generation endpoint
developer.mode.enabled: false

# Whether you want to create the common work item types such as bug, feature, ...
populate.commontypes: true

# -----------------------------
# Authentication configuration
# -----------------------------

token.privatekey : >
                    -----BEGIN RSA PRIVATE KEY-----
                    MIIEpQIBAAKCAQEAnwrjH5iTSErw9xUptp6QSFoUfpHUXZ+PaslYSUrpLjw1q27O
                    DSFwmhV4+dAaTMO5chFv/kM36H3ZOyA146nwxBobS723okFaIkshRrf6qgtD6coT
                    HlVUSBTAcwKEjNn4C9jtEpyOl+eSgxhMzRH3bwTIFlLlVMiZf7XVE7P3yuOCpqkk
                    2rdYVSpQWQWKU+ZRywJkYcLwjEYjc70AoNpjO5QnY+Exx98E30iEdPHZpsfNhsjh
                    9Z7IX5TrMYgz7zBTw8+niO/uq3RBaHyIhDbvenbR9Q59d88lbnEeHKgSMe2RQpFR
                    3rxFRkc/64Rn/bMuL/ptNowPqh1P+9GjYzWmPwIDAQABAoIBAQCBCl5ZpnvprhRx
                    BVTA/Upnyd7TCxNZmzrME+10Gjmz79pD7DV25ejsu/taBYUxP6TZbliF3pggJOv6
                    UxomTB4znlMDUz0JgyjUpkyril7xVQ6XRAPbGrS1f1Def+54MepWAn3oGeqASb3Q
                    bAj0Yl12UFTf+AZmkhQpUKk/wUeN718EIY4GRHHQ6ykMSqCKvdnVbMyb9sIzbSTl
                    v+l1nQFnB/neyJq6P0Q7cxlhVj03IhYj/AxveNlKqZd2Ih3m/CJo0Abtwhx+qHZp
                    cCBrYj7VelEaGARTmfoIVoGxFGKZNCcNzn7R2ic7safxXqeEnxugsAYX/UmMoq1b
                    vMYLcaLRAoGBAMqMbbgejbD8Cy6wa5yg7XquqOP5gPdIYYS88TkQTp+razDqKPIU
                    hPKetnTDJ7PZleOLE6eJ+dQJ8gl6D/dtOsl4lVRy/BU74dk0fYMiEfiJMYEYuAU0
                    MCramo3HAeySTP8pxSLFYqJVhcTpL9+NQgbpJBUlx5bLDlJPl7auY077AoGBAMkD
                    UpJRIv/0gYSz5btVheEyDzcqzOMZUVsngabH7aoQ49VjKrfLzJ9WznzJS5gZF58P
                    vB7RLuIA8m8Y4FUwxOr4w9WOevzlFh0gyzgNY4gCwrzEryOZqYYqCN+8QLWfq/hL
                    +gYFYpEW5pJ/lAy2i8kPanC3DyoqiZCsUmlg6JKNAoGBAIdCkf6zgKGhHwKV07cs
                    DIqx2p0rQEFid6UB3ADkb+zWt2VZ6fAHXeT7shJ1RK0o75ydgomObWR5I8XKWqE7
                    s1dZjDdx9f9kFuVK1Upd1SxoycNRM4peGJB1nWJydEl8RajcRwZ6U+zeOc+OfWbH
                    WUFuLadlrEx5212CQ2k+OZlDAoGAdsH2w6kZ83xCFOOv41ioqx5HLQGlYLpxfVg+
                    2gkeWa523HglIcdPEghYIBNRDQAuG3RRYSeW+kEy+f4Jc2tHu8bS9FWkRcsWoIji
                    ZzBJ0G5JHPtaub6sEC6/ZWe0F1nJYP2KLop57FxKRt0G2+fxeA0ahpMwa2oMMiQM
                    4GM3pHUCgYEAj2ZjjsF2MXYA6kuPUG1vyY9pvj1n4fyEEoV/zxY1k56UKboVOtYr
                    BA/cKaLPqUF+08Tz/9MPBw51UH4GYfppA/x0ktc8998984FeIpfIFX6I2U9yUnoQ
                    OCCAgsB8g8yTB4qntAYyfofEoDiseKrngQT5DSdxd51A/jw7B8WyBK8=
                    -----END RSA PRIVATE KEY-----

token.publickey : >
                    -----BEGIN PUBLIC KEY-----
                    MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnwrjH5iTSErw9xUptp6Q
                    SFoUfpHUXZ+PaslYSUrpLjw1q27ODSFwmhV4+dAaTMO5chFv/kM36H3ZOyA146nw
                    xBobS723okFaIkshRrf6qgtD6coTHlVUSBTAcwKEjNn4C9jtEpyOl+eSgxhMzRH3
                    bwTIFlLlVMiZf7XVE7P3yuOCpqkk2rdYVSpQWQWKU+ZRywJkYcLwjEYjc70AoNpj
                    O5QnY+Exx98E30iEdPHZpsfNhsjh9Z7IX5TrMYgz7zBTw8+niO/uq3RBaHyIhDbv
                    enbR9Q59d88lbnEeHKgSMe2RQpFR3rxFRkc/64Rn/bMuL/ptNowPqh1P+9GjYzWm
                    PwIDAQAB
                    -----END PUBLIC KEY-----


# ----------------------------
# Github OAuth2 configuration
# ----------------------------

github.client.id : 875da0d2113ba0a6951d
github.secret : 2fe6736e90a9283036a37059d75ac0c82f4f5288

Although this is a YAML file, we highly suggest to stick to this rather lenghty notation instead of nesting structs.

To override configuration values using environment variables, use the prefix F8_ and replace the dots in the variables names with underscores.

For example to override postgres.password, set the environment variable F8_POSTGRES_PASSWORD to the value of you liking.

Note
config.yaml is not processed by default. In order to use it, the following environment variable must be set export F8_CONFIG_FILE_PATH="config.yaml"
Note
Environment variables override the default values and the ones you’ve set in your config file.

3.1. Development

Only files ./*.go, ./design/*.go, ./models/*.go and ./tool/wit-cli/main.go should be edited.

These files and directory are generated:

  • ./app/

  • ./assets/js/

  • ./client/

  • ./swagger/

  • ./tool/cli/

  • ./bindata_asstfs.go

4. Developer setup

Start up dependent docker services using docker-compose and runs auto reload on source change tool fresh.

$ cd $GOPATH/src/github.com/fabric8-services/fabric8-wit
$ make dev

The above steps start the API Server on port 8080.

Test out the build by executing CLI commands in a different terminal.

Note
The CLI needs the API Server which was started on executing make dev to be up and running. Please do not kill the process. Alternatively if you haven’t run make dev you could just start the server by running ./bin/alm.
  • Generate a token for future use.

$ bin/wit-cli generate login -H localhost:8080 --pp

You should get access_token in response, set it as env to ease future call:

$ export KEY=<ACCESS_TOKEN>
  • Create a space

$ bin/wit-cli create space -H localhost:8080 --key $KEY --payload '{"data": {"name": "MY_SPACE","path": "","attributes": {"name": "MY_SPACE","description": "description"},"type": "spaces","privateSpace": false}}'

Note the spaceID to be used in next request.

  • Create a workitem for your newly created space

$ bin/wit-cli create workitems -H localhost:8080 --key $KEY --spaceID 564a1296-887e-47fe-9e56-40a39995f585 --payload '{"data":{"attributes":{"system.title":"test","system.description":"","system.state":"New"},"relationships":{"baseType":{"data":{"id":"2c169431-a55d-49eb-af74-cc19e895356f","type":"workitemtypes"}}},"type":"workitems"}}

where baseType in the payload refer to a work item type.

  • List all workitems for a given space:

$ bin/wit-cli list workitems -H localhost:8080 --pp --spaceID 564a1296-887e-47fe-9e56-40a39995f585

4.1. Reset Database

The database are kept in a docker container that gets reused between restarts. Thus restarts will not clear out the database.

To clear out the database kill the database like this:

$ docker kill fabric8wit_db_1 && docker rm fabric8wit_db_1

In case you have mulitple fabric8* running use docker ps to locate the container name.

5. Debugging

System defined Work Item Types are

  • userstory

  • valueproposition

  • fundamental

  • experience

  • feature

  • bug

Use any one of above to create Work Item based on that type. Following example creates a Work Item of type userstory

$ ./bin/wit-cli create workitem --key "<GENERATED TOKEN>" --payload '{ "data": { "attributes": { "system.owner": "tmaeder", "system.state": "open", "system.title": "Example of an Epic", "version": "1" }, "relationships": { "baseType": { "data": { "id": "Epic", "type": "workitemtypes" } } }, "type": "workitems" } }' -H localhost:8080

In response you should get ID of created item, using that you can retrieve the work item.

$ ./bin/wit-cli show workitem --id <ID> -H localhost:8080 --pp

6. Swagger API

A browsable documentation for our API is available with goa Swagger Generator. It reflects the latest state of the master branch.

7. Prod preview setup

In order to setup wit to work against prod preview the following environment variables must be set:

  • export F8_DEVELOPER_MODE_ENABLED=1

  • export F8_OPENSHIFT_TENANT_MASTERURL="https://console.free-stg.openshift.com/"

  • export F8_KEYCLOAK_REALM="fabric8"

  • export F8_CONFIG_FILE_PATH="config.yaml"

Also, F8_TENANT_SERVICEURL env var must be set and point to the prod-preview fabric8-tenant endpoint. However, there is no publicly available route for it and one should oc login to the prod-preview OpenShift Dedicated cluster and use port forwarding for fabric8-tenant pod:

$ oc port-forward <f8tenant-pod> <local-port>:8080
  • export F8_TENANT_SERVICEURL="http://localhost:<local-port>/"

8. che-starter setup

che-starter endpoint can be configure via the following environment variable:

  • export F8_CHESTARTERURL="http://localhost:10000/"

fabric8-wit's People

Contributors

alexeykazakov avatar aslakknutsen avatar baijum avatar corinnekrych avatar dhritishikhar avatar dipak-pawar avatar ebaron avatar fche avatar ibuziuk avatar jarifibrahim avatar jiekang avatar jmelis avatar kbsingh avatar kishansagathiya avatar kwk avatar maxandersen avatar michaelkleinhenz avatar nurali-techie avatar pmuir avatar pranavgore09 avatar preeticp avatar ritsyy avatar sbose78 avatar stooke avatar surajssd avatar tinakurian avatar tsmaeder avatar vineetreynolds avatar vpavlin avatar xcoulon avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  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  avatar  avatar  avatar  avatar  avatar

fabric8-wit's Issues

Show combined coverage

Once #62 is fixed we can show unit and integration test coverage separately but not together. The goal for this issue is to show them as a whole as well.

Include 'help' target in main Makefile

Make file commands
------------------

- all

- build
     These are binary tools from our vendored packages

- clean

- clean-artifacts

- clean-object-files

- clean-generated

- clean-vendor

- clean-glide-cache
     This will download the dependencies

- deps

- generate

- dev

- test-all

- test-unit

- test-integration
     Build artifacts dir

- prebuild-check
     Check that all tools where found

- help
     Shows all the commands and their description

Create releases

Maybe after #12 is done it makes sense to generate releases for all of our supported platforms and put them here.

This makes me think about

  • Jenkins job to do nighty releases
  • Do we want to generate a CHANGELOG
    • automatically?
    • manually written?
    • based on closed issues since last release?

Please comment.

'make test-*' should execute all tests in all packages not just in root

The current setup doesn't resolve correctly.

go test $(go list ./... | grep -v vendor)

I think Make tries to resolve that as a variable? and end up adding ""

go test $$(go list ./... | grep -v vendor) -v -coverprofile 

Works from a resolve all the dirs perspective, but go test doesn't support multiple dirs and profiles.

Move to loop over directories outside of go test ?

Alpina - September 6th Goals

As a user I should be able to by Sept. 6th 2016 (Alpina):

CLI

  • Login to get Token (#118)
  • Create a WorkItemType (CR REST Endpoints, DB Backend) (#119)
    #121
    • Create work item type name Epic with some fields:
      • $ ./bin/alm-cli --host demo.api.almighty.io create workitemtype --payload '{"extendedTypeName":null,"fields":{"system.owner":{"Type":{"Kind":"user"},"Required":true},"system.state":{"Type":{"Kind":"string"},"Required":false}},"name":"Epic"}'
    • Read (Show the work item type named system.issue):
      • $ ./bin/alm-cli --host demo.api.almighty.io show workitemtype --name "system.issue"
    • Fields (Basic understanding of Field types, String, State, User) (#118/#119) #77
      • ID
      • Title
      • Description
      • State
      • Assignee
    • Transitions (Basic understanding of state transition) (#119)
      • Open / Closed
  • Update a WorkItemType (Stretch Goal) (#119)
  • List WorkItemTypes (#119)
    • $ ./bin/alm-cli --host demo.api.almighty.io list workitemtype
  • Execute a query from CLI to import issues from remote issue tracker #24
    • Data to fetch:
      • Title
      • Description (including convertion of Remote text flavor(makrdown/jira wiki))
      • Status (including mapping from Remote status to ALM Planner status)
      • Add link (maybe just as text) back to remote issue.
    • Issues will be added to list of workitems (#170)
  • Remote Provider integration for GitHub (priority 1) #102
  • Remote Provider integration for Jira (priority 1) #103
  • Remote Provider integration for Trello (Stretch goal) #104
  • Remote Provider integration for Bugzilla (Stretch goal) #105
  • View a list of workitems (#118) #101
  • Create a WorkItem (#117) #22
  • View WorkItem (#117/#118) #22
  • Update a WorkItem (#118) #22
  • Transition a WorkItem from Open to Done (#119)

UI

Local test usage (#118)

ID should not be part of the WorkItem PUT/PATCH Payload model

When a Workitem is created it's given ID workitems/:id. To GET a WorkItem you invoke http GET on the id workitems/:id. When you want to update a WorkItem, you should talk to the Resource via the ID workitems/:id.

GET "/workitems" - collection
POST "/workitems" - create a single workitem
GET "/workitems/id" - single workitem
PUT/PATCH "/workitem/id" - update the fields/content of a single workitem

Fix Windows Jenkins job (don't uninstall any git)

Currently we can build on a linux jenkins but on a windows jenkins we have a problem:

Currently there's an issue with installing Git without modifying the global %PATH% and uninstalling any existing jenkins. Locally you don't notice this but when installed on jenkins, all other jobs don't have any Git no more :(

I started to replace the Git installer with a MinGit Zip package and just unpack that but it won't work because the contained git.exe binary is detected as a virus by windows defender.

I've uploaded the archive, the URL to the archive and the binary itself to virustotal to do a scan but nothing was reported there. Whom to trust?

This has a rather low priority. Currently windows jenkins jobs are disabled.

WorkItemType should not be updatable via WorkItem REST PUT/PATCH

The WorkItemType is not a simple Field on the WorkItem and should not be handled like one.

A WorkItem has a relation to a WorkItemType, the REST API should be modeled similarly via relationship links. Update of the relationship changes the link, not the Workitem itself.

A separation between Resource and relationships allow us to trigger special workflows when if this should happen without cluttering the simple WorkItem content update.

Add WorkItemType Field type verification/tests

Verify that a WorkItem's Fields can be converted/verified to the correct Type as defined in the WorkItemType definition.

Create a set of unit tests that verify the different Field Type|Kinds can be handled. (and fix code if not working as expected ;)

Kinds: https://github.com/almighty/almighty-core/blob/master/models/field_definition.go#L11
Workitem: https://github.com/almighty/almighty-core/blob/master/models/workitem.go
WorkItemType: https://github.com/almighty/almighty-core/blob/master/models/workitemtype.go

This sounds like a good case for a Table test: https://github.com/golang/go/wiki/TableDrivenTests

Table could contain: field type, value, expected result
Then the test loop over the table;

  • Creates a WorkItemType with the FieldType
  • Creates a WorkItem with the value
  • Verify expected result when WorkItem is verified against WorkItemType

Ref: https://trello.com/c/nqXR6XHS/66-expand-hardcoded-work-item-types

Improve WorkItemType (de)serialization to JSON by mapping Kind to a String form

Currently, the WorkItemType serialize to JSON very directly:

{
    "BaseType": {
        "Kind": 2
    },
    "Values": [
        2,
        4,
        4
    ]
}

"Kind": 2 is referring to the byte value our internal Kind type has for an Integer. As the WorkItemType JSON format is a user facing format, we should have a Kind in the JSON format that is a little bit less dependent on our implementation detail of this being a byte.

e.g.

"Kind": "String", "String" should then be mapped to and from KindString during JSON Marshal|Unmarshal

Ref: https://trello.com/c/nqXR6XHS/66-expand-hardcoded-work-item-types

Setup Go Vendoring

This is what's left and outsourced into separate issues.

  • Find a working debugger and update the doc on how to debug on command line #55
  • Update the documentation on how to setup an IDE (maybe eclipse, atom, vscode?) #54
  • Fix Windows Jenkins job (don't uninstall any git) #53

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.