Let's take this workflow as an example which is based on the NodeJS starter workflow.
name: continues integration workflow
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: checkout repo
uses: actions/checkout#v2
- name: setup node
uses: actions/setup-node#v1
with:
node-version: '13.x'
- run: npm test
env:
CI: true
What is the purpose of setting CI: true?
Note that since April 2020, you will not see anymore
env:
CI: true
That is because CI is now always set to true, by default.
As noted, this will allow for a script to check if it is running within the context of a CI/CD environment.
You find the same convention in GitLab
Mark that job is executed in CI environment
As far as I can tell, the CI variable is there for compatibility with other CI systems. Here are the facts as I know them:
GitHub Actions itself, does not have any use or need for the CI variable.
Other CI systems - like Travis and CircleCI - always set CI=1.
Unlike other systems, GitHub Actions does not set CI=true, since it is not intended for CI only. Instead, it sets GITHUB_ACTIONS=true.
The conventional use for the CI variable, is so that your tests and app configuration can check for its existence, and do something differently if they need to (for example, skip certain tests on CI, or configure a different setting when on CI).
If your code and test code do not have the CI variable in them, then you can probably omit this setting and have the same result.
Related
I want to setup continuous deployment pipeline between Github and AWS Lambda. For this, I've added main.yml file # myrepo/.github/workflows/main.yml
This is my main.yml file
name: deploy to lambda
on:
# Trigger the workflow on push or pull request,
# but only for the main branch
push:
branches:
- main
jobs:
deploy_source:
name: deploy lambda from source
runs-on: ubuntu-latest
steps:
- name: checkout source code
uses: actions/checkout#v1
- name: default deploy
uses: appleboy/lambda-action#master
with:
aws_access_key_id: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws_secret_access_key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
aws_region: ${{ secrets.AWS_REGION }}
function_name: my_function
source: function.py
Now when I push changes to main branch nothing happens. It shows There are no workflow runs yet. I have checked the function_name and it is same as the function in AWS Console.
Your deploy_source job has runs-on: ubuntu-latest which tells Actions to use a GitHub Hosted Runner. As per your comment, you are using GitHub Enterprise Server (GHES) which is a virtual appliance on your company's network. At present, GHES does not support using GitHub Hosted Runners (it's worth noting at the time of this writing, it is on the product roadmap for support).
If you wish to run your workflow, you will need to make use of a self-hosted hosted runner. I would recommend working with your GHES administrator to get this workflow to run as there are potentially other settings and/or steps that may need to be modified or taken for this to work.
As tj-cappelletti said in their answer, you should use your hosted runners.
And also, be sure that your pipeline is on your default branch. Otherwise, you wouldn't see it there.
You need to place workflows in .github/workflows/. Note the dot in front of the folder name .github. So for your case the final path should look like this myrepo/.github/workflows/main.yml.
I have a github actions workflow, which lints, builds, tests, releases and deploys the software: common CI/CD steps.
This being a FLOSS project, I want to run some jobs for pull-requests and some only when stuff is pushed to main (master) branch and/or tagged. The latter jobs release and deploy the software, so I want to avoid running those when someone makes a PR at all costs.
For the sake of this question details are omitted and all steps abstracted away in shell scripts. The workflow looks like this:
name: CI
on:
push:
branches: [ "main" ]
pull_request:
branches: [ "main" ]
env:
CARGO_TERM_COLOR: always
TAG_FILE: "./job_tags.txt"
jobs:
lint:
runs-on: ubuntu-latest
steps:
- name: Lint
run: lint.sh
build:
runs-on: ubuntu-latest
steps:
- name: Build
run: build.sh
test:
needs: build
runs-on: ubuntu-latest
steps:
- name: Test
run: test.sh
deploy:
needs: [lint, test, build]
if: startsWith(github.ref, 'refs/tags')
runs-on: ubuntu-latest
steps:
- name: Deploy
run: deploy.sh
There are dependencies (needs:) and one if, witch tries to achieve the following:
For all pull_requests to main, run lint, build, test. but not deploy
For all tagged commits to main, run lint, build, test and deploy.
The things I cannot find in the documentation are:
What if someone branches off, creates commits, tags them and then makes a PR. Will that trigger the tags? Do I need extra protection in place to ensure the tag was made on main, of the repo that I hold, and not a fork?
How can I match this on tags with a pattern only? Say v*, only?
Is this feasible in one workflow file? Or should I split the "run for all PRs" and "run only for tagged commits to main" into separate workflows (I'd rather avoid this as it comes with either a lot of complexity -building own reusable actions- or duplication; since I cannot make a job needs: jobs from other workflows).
Is there a function or expression that I'm overlooking which does exactly what I want: filter if this is "my" repo or someone elses in a PR?
I'm experimenting with setting up GitHub Classroom (after getting really tired of manually running tests for student submissions this term). I picked one of the tests from the class I am just finishing, but for the test script I have there, I need Python 3.10; earlier versions won't do.
I tried setting up .github/workflows/classroom.yml to specify the Python version. If I set it to this, in a student repository, I can get my tests to run:
name: GitHub Classroom Workflow
on: [push]
jobs:
build:
name: Autograding
runs-on: ubuntu-latest
steps:
- uses: actions/setup-python#v2
with:
python-version: "3.10"
- uses: actions/checkout#v2
- uses: education/autograding#v1
but (of course) I don't want my students to do this manually whenever they check out an assignment. So, I tried adding the same to the template repository, but that doesn't seem to affect the student repository when I make a new one of those. There, I get the default I got before
name: GitHub Classroom Workflow
on: [push]
jobs:
build:
name: Autograding
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- uses: education/autograding#v1
Is there a way to specify what the workflow should be for an assignment or classroom? Or a way to get it from the template?
Or a way to get it from the template?
Your template could include a workflow, meaning reuse an existing workflow (possible since Oct. 2021)
The "Reusable workflows and workflow templates" section includes:
Inside workflow templates, you can also reference reusable workflows to make it easy for people to benefit from reusing centrally managed workflow code.
If your reusable workflow comes with the right python-version, nothing will have to be set up manually.
I'm currently using the "git-flow" branching model outlined here. Following that model, once I've completed work on a feature branch, I'd like to add new GitHub actions to that branch (for example, to run my feaure's automated tests) before the branch is merged.
Following the branching model, I don't want to define the actions in a workflow file on the default branch before that feature branch is merged into it. Ideally I want to add the actions on the feature branch itself before the merge, but this doesn't appear to work.
I've added the below sample workflow to my feature branch, but GitHub does not detect it. Am I missing something here, or can workflows only detected and run once they're on the default branch? If the latter is true, do people generally merge their branches, then add workflows for them?
# Name workflow
name: Test workflow
# Read only permissions
permissions: read-all
# Triggered once every 15 minutes
on:
workflow_dispatch:
schedule:
- cron: '15 * * * *'
# Listing of jobs to be run
jobs:
# Just output the Python version for now.
python-tests:
name: Python Tests
runs-on: ubuntu-latest
# Use the environment configured with secrets
environment: python-test-environment
# Set the working directory?
defaults:
run:
working-directory: tests
steps:
# Checkout the repository
- name: Checkout
uses: actions/checkout#v2
ref: 'dev-tests'
# Configure Python
- name: Set up Python 3.7
uses: actions/setup-python#v2
with:
python-version: 3.7
# Output the Python version
- name: Display version
run: python -c "import sys; print(sys.version)"
Update: I can see now that the "schedule" trigger only works on the default branch. However, removing it and just using the workflow_dispatch trigger still (on the feature branch YML file) still does not show the workflow on GitHub.
I just started to migrate all my GitLab repositories to GitHub. I wasn't using GitHub for a while so I stumbled over the - at least for me new feature - GitHub Actions.
Since I just started a new project, I wanted to use GitHub Actions for build and deploy my new application. I've really no idea what I'm doing wrong, I'll attach my workflow file below.
What I want to achieve is, everytime I push to a branch that's not my master and that hasn't the prefix 'release/', I want to execute this build and deploy for my development system. Later I will also setup the same script but for a staging (pre production) system ONLY if I push into a branch with the prefix 'release/' and indeed the same a thrid time for production for the master branch only.
What I'm wondering about is, the actions get - at least for my understanding - executed sporadically. I want an behaviour like I had in GitLab: Everytime I push a feature branch or whatever from my local working machine, the development pipeline should get executed. Then I'll create a pull request. Only if the pipeline was successful, I want to be able to merge. After the merge into a branch (for example feature/... into develop), I would like to automatically execute the pipeline for development.
I'm not even sure if this is possible. Maybe I also didn't understood the concept of actions correctly.
name: Publish Development
on:
push:
branches:
- '**'
- '!master'
- '!release/**'
pull_request:
branches:
- '**'
- '!master'
- '!release/**'
jobs:
build-and-deploy:
name: Build and Deploy
runs-on: ubuntu-latest
steps:
- name: check out repository
uses: actions/checkout#v2
with:
token: ${{ secrets.PRIVATE_ACCESS_TOKEN}}
- name: install dependencies
run: npm install
- name: install dependencies
run: npm --prefix ./functions install ./functions
- name: deploy to firebase
uses: w9jds/firebase-action#master
with:
args: deploy
env:
FIREBASE_TOKEN: ${{ secrets.FIREBASE_TOKEN }}
PROJECT_ID: ${{ secrets.FIREBASE_PROJECT_ID }}
Thanks!
EDIT: Well it turned out that I just started to try new technology during some service interruption. GitHub was experiencing some issues in their infrastructure. Its working now as expected.
Well it turned out that I just started to try new technology during some service interruption. GitHub was experiencing some issues in their infrastructure. Its working now as expected.