forked from torvalds/linux
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Signed-off-by: Song Liu <[email protected]>
- Loading branch information
1 parent
9d1110f
commit c4ea2b7
Showing
1 changed file
with
49 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,49 @@ | ||
# This is a basic workflow to help you get started with Actions | ||
|
||
name: CI Test md-6.10 | ||
|
||
# Controls when the workflow will run | ||
on: | ||
# Triggers the workflow on push or pull request events but only for the "main" branch | ||
push: | ||
branches: [ "md-6.10" ] | ||
|
||
# Allows you to run this workflow manually from the Actions tab | ||
workflow_dispatch: | ||
|
||
# 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: local | ||
# the next section is for leveraging a container on the runner, the example | ||
# below shows one called hell-test that is self hosted on the runner. It;s | ||
# commented out because of experiments I'm doing with various ways of using | ||
# containers, runner services, etc. Without it, for example, 2 runners as | ||
# services on the same bare metal will likley step on each other because they | ||
# still share the underlying filesystem. So this is 2 ways of getting container | ||
# isolattion, use the container keyword below and have the container pre-configured | ||
# for our CI work and count on the runner being there likely as a service. OR, | ||
# use containers as runners that also do double duty with actual testing. Pretty syre | ||
# the latter won't work with the stuff below uncommented because docker in docker I think | ||
# has issues but haven't looked into all that much yet. | ||
#container: | ||
# image: localhost:5000/hell-test:1.0.0 | ||
|
||
# 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@v3 | ||
|
||
# Runs a single command using the runners shell | ||
- name: Run a one-line script | ||
run: echo LOCAL UN THIS XXX! | ||
|
||
- name: Compile | ||
run: gcc hello.c | ||
|
||
- name: Runit | ||
run: | | ||
make defconfig | ||
make -j 10 |