Initial checkin nuttx github action CI workflow #261

liuguo09 · 2020-02-13T03:34:27Z

Github action CI workflow steps as below:

Use docker container with build essential tools preinstalled
nxstyle check pull request with checkpatch.sh
Call testing cibuild.sh to do jobs matrix check builds

Now split full testlist into sim/mips-riscv-x86/arm01~arm15 totally 17 jobs to do parallel builds.
All the jobs could be finished in half an hour at most. We could reduce the build time later by refine the configs in each job.

Also note that the pull request check is by default whole file check.

For example, refer to the check build in my own fork:
https://github.com/liuguo09/incubator-nuttx/pull/3/checks

yamt · 2020-02-13T12:14:27Z

is this workflow enabled?

liuguo09 · 2020-02-14T04:30:18Z

Not yet, it just enabled and tested in my own fork. There are still some work (parallel build flock fix and check testlist update) to do before this PR merged.

patacongo · 2020-02-15T14:26:33Z

Does this need an Apache license header? We need to find someone with knowledge on the team to merge this. I do not have the knowledge to do that.

patacongo · 2020-02-15T14:37:10Z

Perhaps someone like @btashton could review and merge this. I will add him as the reviewer and also the the matching PR in apps/

btashton · 2020-02-15T15:57:21Z

Yeah this needs some work. The build job should be abstracted so you can give it a target. Then a build job is defined for each target. That way we can run against all of the configurations including non Linux configs and do them in parallel.

This is normally done by breaking the core of this into it's own action that you then refer to. That can be in this repo or in another.

Also reinstalling dependencies every job is expensive. We should create a container with everything already setup.

btashton · 2020-02-15T15:59:49Z

Also breakings out the action code means that it can almost all live in the testing repo with just a tiny stub here

liuguo09 · 2020-02-18T02:14:48Z

That's right. I'll update with an Apache license header. And consider to use github action docker contianer to preinstall build tools. In addtion, as build job for multi targets, I'll also reconstruct testing code to handle it. It may take some time to test and verify. Thanks.

liuguo09 · 2020-03-05T07:08:30Z

@btashton please help to review. Now use docker container and matrix jobs for parallel builds.

xiaoxiang781216 · 2020-03-05T07:29:23Z

.github/workflows/main.yml

+
+    strategy:
+      matrix:
+        boards: [sim, mips-riscv-x86, arm-01, arm-02, arm-03, arm-04, arm-05, arm-06, arm-07, arm-08, arm-09, arm-10, arm-11, arm-12, arm-13, arm-14, arm-15]


Order the list?

Ok, I'll reorder them.

xiaoxiang781216 · 2020-03-05T07:29:58Z

.github/workflows/main.yml

+    - name: Check Pull Request
+      run: |
+        cd nuttx
+        git log --oneline -5


Why always fetch the first 5 commit? should we count the real patch number in PR?

You are right. I'll update it.

xiaoxiang781216 · 2020-03-05T07:30:54Z

.github/workflows/main.yml

+    - name: Fetch nuttx tags
+      run: |
+        cd nuttx
+        git fetch --tags


Why need fetch tag?

Since tags is needed to generate the .version file, or it would build break at first : (

This can be done in the checkout step https://github.com/actions/checkout#fetch-all-tags

This can be done in the checkout step https://github.com/actions/checkout#fetch-all-tags

Since I'm using the with option for checkout@v2 action, the run step seems not work together. I'll double check it.

I have checked that the instructions in the https://github.com/actions/checkout#fetch-all-tags run two steps too.
So it doesn't make much sense to use same as it.

I guess the cost is low for the two steps, but other examples there like submodules show two run lines which I think makes sense to just get everything done. But these are really later optimizations.

xiaoxiang781216 · 2020-03-05T07:51:33Z

@davids5, @maht and @yamt , please take a look

davids5 · 2020-03-05T09:42:29Z

@davids5, @maht and @yamt , please take a look

Where can we see it running?

liuguo09 · 2020-03-05T09:53:33Z

@davids5, @maht and @yamt , please take a look

Where can we see it running?

This is one PR check build in my own fork:

https://github.com/liuguo09/incubator-nuttx/pull/3/checks

davids5 · 2020-03-05T10:01:20Z

@liuguo09 - Nice!

What % of board configs are being built (n of N)?
What is the total build time?
What is the limit on jobs? Are we there yet?

liuguo09 · 2020-03-05T12:49:30Z

@liuguo09 - Nice!

What % of board configs are being built (n of N)?

Now support the following arch: arm/sim/mips/risc-v/x86
arm 455/478
sim 30/34
mips 11/11
risc-v 7/9
x86 2/2

And haven't enabled the following archs build since lack of toolchains. If available, we could update the docker container to preinstall their toolchains and update testlist to build them.
avr 0/11
hc 0/2
misoc 0/2
or1k 0/1
renesas 0/10
x86_64 0/1 // link issue need resolved
xtensa 0/3
z16 0/2
z80 0/17

What is the total build time?

There are two stages in PR check build.
The first stage is the PR nxstyle check, it takes nearly 2 minutes(mainly pull docker container).
And the second stage is matrix jobs build which depend on the first stage success. Now each job builds about 30 configs in parallel which take nearly 20+ minutes.
If both the two stages succeed, it would spend at most half an hour in whole from my testing.

What is the limit on jobs? Are we there yet?

For github action free version, there are 20 jobs upper limit. And now used 17 jobs here. Each job runs in an 2-cores cpu container. More limits about github action, refer to:
https://help.github.com/en/actions/getting-started-with-github-actions/about-github-actions#usage-limits

xiaoxiang781216 · 2020-03-05T14:03:07Z

What is the limit on jobs? Are we there yet?

For github action free version, there are 20 jobs upper limit. And now used 17 jobs here. Each job runs in an 2-cores cpu container. More limits about github action, refer to:
https://help.github.com/en/actions/getting-started-with-github-actions/about-github-actions#usage-limits

We reserve 3 VM interntionally for two purposes:
1.Build the remainning config(total 78)
2.Test Windows(native, cygwin, msys) and macOS build environment

btashton

This looks great overall. I am excited to get this in and then work on getting the mac and windows configurations going.

Also I do not think it is required for this first step, but adding build artifacts to the builds would be awesome as well since one could just grab a elf and the debug symbols for a build and throw it on a board to do some other validation on hardware. https://help.github.com/en/actions/configuring-and-managing-workflows/persisting-workflow-data-using-artifacts

btashton · 2020-03-06T01:23:23Z

.github/workflows/main.yml

+name: PR Check CI
+
+on:
+  pull_request:


Should we not also run on the push event? Also I think this restricts to pull requests off master which might not be what we want if there is a long running feature branch. I think is can just be this.
on: [push, pull_request]

I see that it by default includes synchronize so probably fine to leave it, but I would drop the branch. Maybe we still want to keep the push but limited to branch master so there is always a build on master
something like this:

on: pull_request push: branches: [master]

@liuguo09 also if you have your Dockerfile somewhere I would be happy to submit a PR against it to improve it a bit. There is some low hanging fruit that would reduce the size by quite a bit.

Yes, that's great. I meant to add the Dockerfile into nuttx testing repo. I'll add it later. Then you could update it there.

I see that it by default includes synchronize so probably fine to leave it, but I would drop the branch. Maybe we still want to keep the push but limited to branch master so there is always a build on master
something like this:

on: pull_request push: branches: [master]

Yes, besides master branch, pull request check for feature branch would also be useful.
Now I use the pull request git log "Merge new-commit-id into old-commit-id" to filter commits in the PR and then do checkpatch.sh. But for master push, it should not work and skip. Just see the github action job steps.if could be used to judge it. I'll update it later.

Update on trigger pull request for all branches. As to push event, I think it may be not necessary since there is no committer push master directly.

I think it captures the merge situation which is what I'm worried about.

There is also the nightly build to make the full build although it's per day.

btashton · 2020-03-06T01:24:54Z

.github/workflows/main.yml

+    - name: Fetch nuttx tags
+      run: |
+        cd nuttx
+        git fetch --tags


This can be done in the checkout step https://github.com/actions/checkout#fetch-all-tags

btashton · 2020-03-06T01:31:43Z

@liuguo09 also if you have your Dockerfile somewhere I would be happy to submit a PR against it to improve it a bit. There is some low hanging fruit that would reduce the size by quite a bit.

liuguo09 · 2020-03-06T02:39:24Z

This looks great overall. I am excited to get this in and then work on getting the mac and windows configurations going.

Also I do not think it is required for this first step, but adding build artifacts to the builds would be awesome as well since one could just grab a elf and the debug symbols for a build and throw it on a board to do some other validation on hardware. https://help.github.com/en/actions/configuring-and-managing-workflows/persisting-workflow-data-using-artifacts

IMO, It's a good idea. The build artifacts stage could be added in future if agreed and it doesn't add much time.

xiaoxiang781216 · 2020-03-06T04:21:25Z

Yes, we can select some images(sim, x86, x86-64, qemu for arm/riscv/xtens..) as build artifacts and run the testsuite on this images automatically.

liuguo09 · 2020-03-06T06:45:15Z

@liuguo09 also if you have your Dockerfile somewhere I would be happy to submit a PR against it to improve it a bit. There is some low hanging fruit that would reduce the size by quite a bit.

I have just made PR here the Dockerfile.
apache/nuttx-testing#13

Github action CI workflow steps as below: 1. Use docker container with build essential tools preinstalled 2. nxstyle check pull request with checkpatch.sh 3. Call testing cibuild.sh to do jobs matrix check builds Signed-off-by: liuhaitao <liuhaitao@xiaomi.com>

btashton

I'm happy to get this in as is and then incrementally move forward.

patacongo requested a review from btashton February 15, 2020 14:37

liuguo09 force-pushed the master branch 2 times, most recently from 5839f4a to e652363 Compare March 5, 2020 06:13

xiaoxiang781216 reviewed Mar 5, 2020

View reviewed changes

xiaoxiang781216 mentioned this pull request Mar 5, 2020

Travis CI configuration #183

Closed

xiaoxiang781216 mentioned this pull request Mar 5, 2020

Example of use of tools/Jenkinsfile #174

Closed

liuguo09 force-pushed the master branch 2 times, most recently from 1b54753 to 7746288 Compare March 5, 2020 09:14

xiaoxiang781216 mentioned this pull request Mar 5, 2020

Initial checkin nuttx-apps github action CI workflow apache/nuttx-apps#113

Merged

btashton reviewed Mar 6, 2020

View reviewed changes

liuguo09 force-pushed the master branch from 7746288 to 4c001cf Compare March 6, 2020 14:59

btashton approved these changes Mar 6, 2020

View reviewed changes

xiaoxiang781216 merged commit d7fa6a9 into apache:master Mar 6, 2020

Initial checkin nuttx github action CI workflow #261

Initial checkin nuttx github action CI workflow #261

Uh oh!

Conversation

liuguo09 commented Feb 13, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

yamt commented Feb 13, 2020

Uh oh!

liuguo09 commented Feb 14, 2020

Uh oh!

patacongo commented Feb 15, 2020

Uh oh!

patacongo commented Feb 15, 2020

Uh oh!

btashton commented Feb 15, 2020

Uh oh!

btashton commented Feb 15, 2020

Uh oh!

liuguo09 commented Feb 18, 2020

Uh oh!

liuguo09 commented Mar 5, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xiaoxiang781216 commented Mar 5, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

davids5 commented Mar 5, 2020

Uh oh!

liuguo09 commented Mar 5, 2020

Uh oh!

davids5 commented Mar 5, 2020

Uh oh!

liuguo09 commented Mar 5, 2020

Uh oh!

xiaoxiang781216 commented Mar 5, 2020

Uh oh!

btashton left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

liuguo09 commented Feb 13, 2020 •

edited

Loading

xiaoxiang781216 commented Mar 5, 2020 •

edited

Loading