I want this step to only execute on the master branch
- name: test_step
type: Bash
execution:
onExecute:
- echo 'Hello world'
How do I ensure that this step only runs on the master branch?
Yes, we can execute any step based on condition using condition workflows https://www.jfrog.com/confluence/display/JFROG/Conditional+Workflows
In order to achieve your scenario, you can do something like:
- name: test_step
type: Bash
configuration:
condition: '{{gitBranch}} == master'
execution:
onExecute:
- echo 'Hello world'
where {{gitBranch}} is a pipeline variable available to be used in pipelines yml and can be used as a placeholder for whatever branch the pipeline was loaded from. When Pipelines syncs from the pipeline source, it automatically replaces any occurrence of {{gitBranch}} with the name of the current branch.
Related
I have configured a manual workflow and it runs OK, but once I update/edit it and commit it to the same branch, the changes do not affect it. I mean the action still runs but uses the old version of the workflow file. is there any step I need to do?
Steps I followed for editing the workflow file:
https://docs.github.com/en/actions/learn-github-actions/finding-and-customizing-actions#browsing-marketplace-actions-in-the-workflow-editor
Here is workflow file details, just in case
The original:
# This is a basic workflow to help you get started with Actions
name: CI
# Controls when the workflow will run
on:
# Triggers the workflow on push or pull request events but only for the "development" branch
release:
types: [created]
# 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: 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#v3
# Runs a single command using the runners shell
- name: Run a one-line script
run: echo Hello, world Nikzad!, 3
Note: Let's say I just replace the last line with the bellow line, but my output still says Hello, world Nikzad!, 3 where it should say Hello, world Nikzad!, 4.
run: echo Hello, world Nikzad!, 4
I found my problem. actually, when we are creating a new release, we are providing a tag name for that release, and when we create that tag name and push it to the repo, the version of the workflow at that point is what matters, so when I want to edit or update my workflow, I do the followings:
Edit the workflow (Make any change you want, eg change the title or add echo)
Commit and push workflow changes
Create a new tag and push
From the GitHub panel, create a new release based on the new tag
Now I see the action is running based on the new workflow
Note: Maybe it is more about learning of the process, but I did not find it straight forward anywhere, I hope it helps someone.
I placed a checks configuration on my git repository.
Then I added a yaml pipeline to the same directory.
If I run the pipeline all checks or approvals are ignored independent of the type as if they don't exist.
In the log of the job I can see that the repositoy is accessed (default checkout of self).
Do checks on resources with type repository get only executed under special circumstances?
Am I missing something?
I want to force the pipeline to extend a dedicated template regardless which environment is used.
here the pipeline source, that I expected to fail:
trigger:
- main
- users/*/*
- features/*
pool:
vmImage: ubuntu-latest
steps:
- bash: echo "hello world"
displayName: echo something
I checked the same checks on the agent pool and that works as expected. It fails the pipeline if that does not extend the template.
template check configuration
Case: I have a azure Devops pipeline which deploys code to PRODDUCTION. It takes tag name (tag created by developer on master branch commit) as input, so that it can deploy only that specific version of code from master branch. This pipeline is set as no auto trigger, developers tag the commit in master branch & given that tag name to operation team to enter it as run time parameter (input to the pipeline)
I check out code using checkout steps with in deploy job of azure devops pipeline.
deploy:
steps:
- checkout: git://MY_PROJECT/MY_REPO#refs/tags/${{variables.tag_name}}
Query: How to assure (before deployment) that this tag is from master branch only and not from other non-master branches. (developers can create tag on master branch also)
I know we can use script like 'git commit --contains' & 'git describe' but how can we handle it efficiently any suggestion and best practices around this.
have you tried :
trigger:
- master
You can also use a powershell step to control the source branch of the artifact linked in that release with the "Build.SourceBranch" system variable
I ran into the exact same issue. I solved it by adding following check as the first step in the deployment pipeline.
steps:
- checkout: self
clean: true
persistCredentials: true
- bash: |
set -e
COMMIT_ID=$(Build.SourceVersion)
BRANCH=master
git checkout $BRANCH
RES=$(git branch --contains $COMMIT_ID)
if [[ -z $RES ]]; then
exit 1
fi
exit 0
condition: startsWith(variables['Build.SourceBranch'], 'refs/tags/')
Basically we check that the tagged commit is on the master branch. If not the deployment pipeline fails at this point without ever deploying the tagged version of the code.
I have two Azure DevOps yaml pipelines, one for building and then one deploying (yes I know I can do both in a single pipeline, but for my use case I need to split it).
The first pipeline builds artifacts and I have then configured the second pipeline to be triggered when the first complete to deploy those artifacts.
I am trying to get my second pipeline to have the same name as the first pipeline, to make it easy to correlate the two.
So, if the first pipeline runs and is automatically named '1.0.0', I want the second pipeline to also be named '1.0.0' when it is triggered.
My first pipeline (below) starts as follows and has an automatically generated semantic name.
# Generate build name - see variables section below
name: '$(Version.MajorMinor).$(Version.Revision)$(Version.Suffix)'
# These are Continuous Integration Triggers for automatically starting a new pipeline run when there is a check in for any of the matching branches
trigger:
- trunk
- feature/*
- task/*
- bug/*
# Use this section to set variables that are specific to the Microservice / Solution being processed
variables:
Version.MajorMinor: 1.0 # Major = non-backward compatible version increment, Minor = backward compatible version increment
Version.Revision: $[counter(variables['Version.MajorMinor'],0)] # Increments automatically every build, resets if Version.MajorMinor is changed
# Set the suffix of the version number depending on whether this is trunk, pr or other branch
${{ if eq(variables['Build.SourceBranch'], 'refs/heads/trunk') }}:
Version.Suffix: '' # trunk
${{ if eq(variables['Build.Reason'], 'PullRequest') }}:
Version.Suffix: '-pr' # pull request
${{ if and(ne(variables['Build.SourceBranch'], 'refs/heads/trunk'), ne(variables['Build.Reason'], 'PullRequest')) }}:
Version.Suffix: '-pre' # pre-release
My second pipeline starts:
# Use the name of the first pipeline
name: '$(originalVersion)-test'
resources:
pipelines:
- pipeline: original # reference to build pipeline
source: 'DevOps - CI'
branch: trunk
variables:
# variable contains the name of the build pipeline
originalVersion: $[variables['resources.pipeline.original.runName']]
stages:
- stage: start
jobs:
- job: LogJob
displayName: 'Logging'
steps:
- checkout: none
- pwsh: |
Write-Host "originalVersion: $(originalVersion)"
Write-Host "pipelineID: $(resources.pipeline.original.pipelineID)"
Write-Host "runName: $(resources.pipeline.original.runName)"
Write-Host "runID: $(resources.pipeline.original.runID)"
Write-Host "runURI: $(resources.pipeline.original.runURI)"
Write-Host "sourceBranch: $(resources.pipeline.original.sourceBranch)"
Write-Host "sourceCommit: $(resources.pipeline.original.sourceCommit)"
Write-Host "sourceProvider: $(resources.pipeline.original.sourceProvider)"
Write-Host "requestedFor: $(resources.pipeline.original.requestedFor)"
Write-Host "requestedForID: $(resources.pipeline.original.requestedForID)"
displayName: "PoSh: Dependant Pipeline Details"
I've added '-test' to the name of the second pipeline in order to debug, as when the pipeline is triggered by the first completing the name it assigned is just '-test'.
However, in the logging job, it correctly prints out the name of the previous build, specifically these two lines both print out '1.0.0'
Write-Host "originalVersion: $(originalVersion)"
Write-Host "pipelineID: $(resources.pipeline.original.pipelineID)"
but using that variable in the 'name:' property results in an empty value.
In the first pipeline, I am able to use variables in the build name generated from expressions (the incrementing version number) but in the second pipeline, the variable substitution does appear to work.
Can anyone spot if I'm doing something daft, or is this a bug/limitation in Azure DevOps YAML?
Because the name value is evaluated before the variables are created. as a workaround you can add a simple script that updates the name:
- script: echo "##vso[build.updatebuildnumber]$(originalVersion)"
Result:
I want to run periodically ipynb file in my github repository (Like every 30 minutes).
I know that I can use Github Action to create yml file for this progress but I have no idea how to reorganize yml file.
How can I do it?
Here is my test tml file defined below.
# 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:
schedule:
- cron: '*/5 * * * *'
push:
branches: [ master ]
pull_request:
branches: [ master ]
# 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
# Runs a single command using the runners shell
- name: Run a one-line script
run: echo Hello, world!
# Runs a set of commands using the runners shell
- name: Run a multi-line script
run: |
echo Add other actions to build,
echo test, and deploy your project.
You can check out this GitHub action that runs your jupyter notebook and lets you upload the artifacts. As for how to organize your workflow file, you can read the documentation here.