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

added blank ci #9

Merged
merged 4 commits into from
Apr 23, 2020
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 28 additions & 0 deletions .github/workflows/blank.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,28 @@
# This is a basic workflow to help you get started with Actions
name: CI

# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the master branch
on:
push:
branches: [ T-8 ]
pull_request:
branches: [ T-8 ]
Comment on lines +8 to +10
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@alifiratari Should they be "master" before we merge to master branch?


# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
# This workflow contains a single job called "build"
build:
# The type of runner that the job will run on
runs-on: ubuntu-latest

# Steps represent a sequence of tasks that will be executed as part of the job
steps:
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- uses: actions/checkout@v2

# Compile!
- name: Run makefile
run: |
echo Compiling..
make
67 changes: 67 additions & 0 deletions .github/workflows/coverity-scan.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,67 @@

# This is a basic workflow to help you get started with Actions
name: Coverity Scan

# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the master branch
on:
#schedule:
# - cron: '0 18 * * *' # Daily at 18:00 UTC
push:
branches: [ T-8 ]
pull_request:
branches: [ T-8 ]

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
# This workflow contains a single job called "build"
build:
# The type of runner that the job will run on
runs-on: ubuntu-latest

# Steps represent a sequence of tasks that will be executed as part of the job
steps:
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- uses: actions/checkout@v2
- name: Install dependencies
run: |
echo Installing Dependencies
echo Compiling..
set -x
sudo sed /etc/apt/sources.list -e "s/^# deb-src/deb-src/g" -i
sudo apt-get update -y
sudo apt-get install -y wget tar
sudo apt-get install -y build-essential
###
- name: Download Coverity Build Tool
run: |
wget https://scan.coverity.com/download/linux64 --post-data "token=k6qP6g2jPgQpCUHmsCscKA&project=EmbeddedTemplate" -O coverity_tool.tgz
wget -q https://scan.coverity.com/download/cxx/linux64 --post-data "token=$TOKEN&project=EmbeddedTemplate" -O cov-analysis-linux64.tar.gz
mkdir cov-analysis-linux64
tar xzf cov-analysis-linux64.tar.gz --strip 1 -C cov-analysis-linux64
env:
TOKEN: ${{ secrets.COVERITY_SCAN_TOKEN }}
###
- name: Fixed world writable dirs
run: |
chmod go-w $HOME
sudo chmod -R go-w /usr/share
# Generating a output for send to Covertiy Scan
- name: Build with cov-build
run: |
export PATH=`pwd`/cov-analysis-linux64/bin:$PATH
cov-build --dir cov-int make
# Sending the output
- name: Submit the result to Coverity Scan
run: |
tar czvf EmbeddedTemplate.tgz cov-int
curl \
--form project=EmbeddedTemplate \
--form token=$TOKEN \
--form [email protected] \
--form [email protected] \
--form version=trunk \
--form description="`./EmbeddedTemplate -v`" \
https://scan.coverity.com/builds?project=EmbeddedTemplate
env:
TOKEN: ${{ secrets.COVERITY_SCAN_TOKEN }}
3 changes: 3 additions & 0 deletions .gitignore
Original file line number Diff line number Diff line change
Expand Up @@ -50,3 +50,6 @@ modules.order
Module.symvers
Mkfile.old
dkms.conf

# Project specific
out/
49 changes: 49 additions & 0 deletions Documents/LifeCycle.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
**Open IoT Academy**

**Software Development Life Cycle** : V Model of Development

Open IoT Academy is an open source organisation and produces high assurance and high quality software for IoT.

For this purposes, Open IoT Academy uses **V Model of Development Life Cycle** for its open source development.

​ *In this document, we do not detail V Model of Development; for details please see [Wikipedia](https://en.wikipedia.org/wiki/V-Model_(software_development)).*

![V-Model-Of-Development](https://github.com/OpenIoTAcademy/Resources/blob/master/Images/VModelOfDevelopment.jpg)

Please see the phases for the V Model of Development;

- **External Requirements**: In this phase, the external requirements (e.g. User Expectations) for the final product needs to be defined using the external resources such as product or standard specs.

- **External Tests**: Once the external requirements are defined, the tests need to be implemented to validate the feature. There is no implementation about the final product yet, therefore, mock implementation needs to be done for the external interface to pass the external tests.

Automated test infrastructure for the external tests must be up and run in this phase and must be run for each modification during the development.

- **Internal Requirements**: In this phase, the external requirements are translated to internal requirements (internal design documentation). The architecture team prepares the software design including components, modules, roles and interactions between each other.

- **Integration Tests**: Integration tests are defined and implemented. There is no implementation yet so mock implementation needs to be done for the integration tests.

Automated test infrastructure for the integration tests must be up and run in this phase and must be run for each modification during the development.

- **Module Requirements**: Internal requirements are split into stand-alone modules/units and requirements are defined for the Unit.

- **Unit Tests** : Like Test Driven Development(TDD), Unit tests are defined and developed for the unit. There is no implementation yet so the mock implementation are done for the unit.

Automated test infrastructure for the unit tests must be up and run in this phase and must be run for each modification during the development.

In the unit test, in addition to automated test, there can be some metrics, and SW Quality tools can be a part of the tests.

Some examples;

- Static Analysis Tool
- Dynamic Analysis Tools
- Code Coverage Tools (%100 requirement)
- MISRA-2012 checker

All unit level modifications must meet all above requirements.

- **Development**: Development is the latest phase in the V Model of Development. All automated testing and Continuous Integration(CI) interface is ready and any modification is well tested with the testing infrastructure. In this way, a bug can be found immediately as soon as the bug introduced. Each modification(commit) has the final product quality (well tested).

All errors and even warnings must be blocker and the Continuous Integration(CI) tool must not allow the modification to be part of the main code stream (master branch).



5 changes: 5 additions & 0 deletions Include/test.h
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
/**
* @brief A test header
*/

void testFunction(void);
3 changes: 3 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,2 +1,5 @@
# EmbeddedTemplate
Template Project For Embedded Projects

![CI](https://github.com/alifiratari/EmbeddedTemplate/workflows/CI/badge.svg?branch=T-8)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What it is for? If it is required can you please add comments?

![CI](https://scan.coverity.com/projects/20937/badge.svg?branch=T-8)
23 changes: 23 additions & 0 deletions Source/test.c
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@

/**
* @brief a test source file
*/

#include "test.h"

#include <stdio.h>

#ifndef TEST_CONFIG
#error "TEST_CONFIG is not defined"
#endif /* TEST_DEFINE */

void testFunction(void)
{
printf("\r\nHello World!");
printf("\r\nTest Config Value : %d\r\n", TEST_CONFIG);
}

int main(void)
{
testFunction();
}
67 changes: 67 additions & 0 deletions makefile
Original file line number Diff line number Diff line change
@@ -0,0 +1,67 @@
#
# The root makefile
#

OUTPUT_PATH=out
OUTPUT_NAME=test

# The cross compile if exists, otherwise uses the gcc
CROSS_COMPILE?=

#
# Source (.c) Files
#
SOURCE_FILES= \
Source/test.c

#
# Header (.h) File Directories
#
# Bear in mind, include directories must have -I prefix
#
INCLUDE_DIRECTORIES= \
-IInclude/

#
# Project Definitions
#
# Bear in mind, definitions must have -D prefix
#
DEFINES= \
-DTEST_CONFIG=255

#
# All Flags
#
CFLAGS=${INCLUDE_DIRECTORIES} ${DEFINES}


#############################################
# Rules
#############################################


#
# The main rule
#
all: out test

# Rebuild
rebuild: clean all

# The test rule
test:
${CROSS_COMPILE}gcc -g ${SOURCE_FILES} ${CFLAGS} -o ${OUTPUT_PATH}/${OUTPUT_NAME}

# The clean rule
clean:
rm -f test

# The rule to create out path
out:
mkdir -p ${OUTPUT_PATH}

# The rule to run the output executable
run:
./${OUTPUT_PATH}/${OUTPUT_NAME}