overdrivr / micro-ci Goto Github PK

Modify npm run unit command to evaluate test coverage

Create a custom logout route, and implement logic to terminate a passport session.

See http://passportjs.org/docs

Change jenkins library from Silas to an other one. This one is using to much home made function.

Check what happens if one of both fields repository or after are undefined

Test strategy
With protractor:

1. Go to micro-ci \login page
2. Click login with github button
3. Authorize on github page
4. Redirection on micro-ci. Detectable ?
5. ?
   Question is, which user account to use for testing the connection ? Because google or github may not be fond of creating robot accounts for testing purposes

For a given repo & commit sha, grabs the micro-ci.yaml file and checks it.

When you run the e2e test for slave more slave are boot than necessary. This error could come from of asynchronous callback on build creation and check_and_boot method from slave model

Used for notifying the server when a Jenkins build is finished

Create a remote method api/Repository/activate to enable continuous integration on a repository.

This method will follow the following algorithm:

1. check the repository to activate exists
2. check the user requesting the activation is the owner
3. check if a repo already exists in the DB (re-activation). If yes, mark it back as active. If not, instanciate a new one
4. request github to create a webhook on this repository. Generate a unique key (on a per-repository basis) to provide to github to ensure afterward that it is github calling our webhook. This is related to #34

• build.js : use Promises ?
• ?

Create a jenkins docker so it will be easy to boot it with the good configuration.

For public repositories, all build info should be public which is default behavior.
For private repositories, build info should only be accessible by accredited people.

How to define this list ?

• Collaborator list from github/bitbucket
• Manual setting

If we are using only collaborator list from github, this means only users that will authenticate to micro-ci through github will be able to be identifed as accredited viewers for this repository.

For the moment the e2e test is only a shell test with no autocheck. Migrate it to a mocha test with auto test.

We should have a timeout on booting slave in case it never boot to start a new slave.

Create integration test to check the deployment of Jenkins. This test is independent from jenkins node library as they will use supertest to validate it.

• Create Job model
• Create Log model
• Relations - also with Build model

Scaffold a slave model. Which contain:

• IP of the slave
• Status:
  • Booting
  • Building

Each slave is boot for running a specific build.

On webhook commit event or manual user request, module gather all informations, creates a new Job, all related Builds, and requests them all to be executed through Jenkins

Hello Remi,

I was looking to your code and I found this:

var providers = require('../providers.example.json');

In passport-providers.js. I think it should be "providers.json"

Move to ./test/unit/

Perform the test for:

1. An user authenticated to micro-ci through Github
2. An user authenticated to micro-ci through custom account
3. An user authenticated to micro-ci through another third party service (Google)

Configure express-session so that a 🍪 is left client-side to maintain the session after browser has closed.
For testing, maxAge should be set to something small, like one hour 🔔

Ping payloads do not have a after value (containing a commit hash) unlike push payloads.
Currently the server is not able to detect that the payload is a ping, looks for the commit in the database with hash == after, and since it is undefined, returns the entire database (fullmatch) instead of returning nothing.

Instead, it should detect the payload as ping, and if the repository exists return 204, if not 404 otherwise.

OAuth2.0 authentication now working with persisted data.

2 types of credentials to persist:

• UserIdentity: Used to store a third-party profile used for login on micro-ci
  Ex: Github, Google, Twitter
• UserCredentials: Used to store credentials on a third party service (link third party profile to micro-ci profile)

For now, OAuth application ClientID and ClientSecret are put into versionning.

Need to remove those credentials from inside the code, recreate them from scratch using github/google/etc consoles and put new credentials inside environment variables so that they are not versionned.

To help to create the yaml file. The user should be able to edit it online and try it. Once it is passing micro-ci will automaticly to a PR to the repo with the new yaml file.

Jade templating + JQuery ?
AngularJS ?

Same test sequence as #17

Implement the logic to process Github webhook request.
Use test driven development. Build a fake request by refering to Github documentation

Each test suite should clear the cache and instanciate its own set of models inside the database.

Scaffold a node js script which will manage, boot and reboot of slave depending on the ressource returned need returned by jenkins.

Implement connection flow with github
Setup local tests
Create a new model Account (github, bitbucket, etc) linked to Client (Client hasMany Accounts)

Context

Two conditions for the creation of a Job:

• call (from github) to api\Repositories\webhook\github
• call (from authenticated client) to api\Commits\{id}\build

Both call will trigger the creation of a job, which in return will create one or more build(s) depending on the repository configuration.

Proposal

Modify the create method or implement a custom method for Job, with node API (not exposed to REST), that does the following:

1. Find belongTo commit
2. Find belongTo repository
3. For now, fake the library (that must be written in the future) that grabs from repository git adress and commit sha the yaml file and extracts a configuration list. Instead, act as if there was a single config in the list.
4. Create a build for each config list entry

Tests

• Test @ node API level with default config that a single job and a single build is created
• Test @ node API level with mocked config that generates 3 builds that a single job is created and three builds are instanciated
• Test @ REST API level that a call to webhook endpoint creates a job
• Test @ REST API level that a call to manual build enpoint creates a job

Implement the yaml parser and check yaml file

In Repository.js
https://github.com/Overdrivr/micro-ci/blob/master/common/models/repository.js#L33

This line does nothing, array can be empty meaning no repository was found, yet it won't return early since the array is defined but empty. Rookie mistake.

Instead, array.length == 0 should be checked

• jade (use pug because jade package was renamed)

Scaffold a plateform model which belongs to a build.
Will contains name, gcc, lflags, cflags....

So that github, bitbucket, etc can alert on commit to create job

After migrating jenkins test in the unit folder I got this issue:

  1) jenkins JobSucess Job succes:
     Uncaught TypeError: Cannot read property 'items' of undefined
      at Jenkins.<anonymous> (node_modules/jenkins/lib/middleware.js:25:35)
      at next (node_modules/jenkins/node_modules/papi/lib/client.js:298:10)
      at Jenkins._onResponse (node_modules/jenkins/lib/jenkins.js:109:3)
      at next (node_modules/jenkins/node_modules/papi/lib/client.js:298:10)
      at IncomingMessage.<anonymous> (node_modules/jenkins/node_modules/papi/lib/client.js:598:7)
      at _stream_readable.js:920:16

Any idea?

Simulate a webhook call crafted by someone else than github (webhook secret should not match)

If a users wants to remove micro-ci on a repo, there are different possible use cases:

• Users delete a repo through REST API. This means removing all repo/commit/job/build data from the database
• Users activate and deactivate a repo through REST API. First time a repo is activated is it persisted into the database. Concretely, this means the user cannot remove its data from the database for now

Which one do you think we should implement @DanFaudemer ? I personnally have a preference for the second

Need a basic frontend page for being able to:

• Register micro-ci to Github OAuth2 service

To test locally, see this SO post for advices:

• http://stackoverflow.com/questions/10456174/oauth-how-to-test-with-local-urls

Lock models endpoints for Client, Repository, etc.
Global lock per model + authorize endpoints per case basis