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.
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 trigger in azure-pipelines.yaml like below.
resources:
repositories:
- repository: APPLICATION
type: git
name: AAA/APPLICATION
ref: master
- repository: TESTS
type: git
name: AAA/TESTS
ref: master
STAGES:
- stage : BuildApplication
// checkout branch & build necessary things
- stage : BuildTests
// checkout branch & build necessary things
Since the yaml resides in Application repository, While creating manual CI build I am able to select the Branches in Application repository & for Tests repository the branch checkout will be master always.
is there any was I can able to set the branch details of Tests repository before creating release ?
Is there any was I can able to set the branch details of Tests repository before creating release ?
From your YAML sample, you need to select the Resource Repo branch when manually running the pipeline.
I am afraid that there is no out-of-box method can select the resource repo branch. The branch is defined at resources field. When you running the pipeline, it will use the default branch.
For a workaround, you can change to define the repo in check out field. You can use paramter to define the repo branches and then you can select the branch when you running the pipeline.
Refer to this doc: Inline syntax checkout
Here is an example:
parameters:
- name: test
values:
- refs/heads/main
- refs/heads/test1
pool:
vmImage: ubuntu-latest
steps:
- checkout: git://azure/Repo13#${{ parameters.test }}
Result:
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 trying to wrap my head around GitHub actions as well as how YAML is parsed.
For obvious reasons, I'd like to make use of actions already available on the marketplace. This is what I have so far..
- name: Bump Version
on:
pull_request:
branches:
- main
jobs:
bump-patch:
runs-on: ubuntu-latest
steps:
- name: Get current package version
uses: martinbeentjes/npm-get-version-action#v1.1.0
with:
# Path to package.json file (directories only), e.g. packages/mypackage/
path: ./
- name: Bump Patch Version
uses: jessicalostinspace/bump-semantic-version-action#v1.0.1
with:
semantic-version: 1.0.0
version-type: PATCH
So a few obvious things.. I need to read the current package/bower version in order to Bump it correctly with the action. I also need to make sure the branch in the PR is the one that gets updated and commits the change to that branch. Additionally the action should only run depending on the user who opened the PR.
The question:
Is it even possible to do this with GitHub actions or would a github app/service be better suited?
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.