-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Trigger pipelines for azure #353
Conversation
Codecov Report
@@ Coverage Diff @@
## main #353 +/- ##
==========================================
+ Coverage 93.89% 94.32% +0.43%
==========================================
Files 149 152 +3
Lines 5468 5514 +46
==========================================
+ Hits 5134 5201 +67
+ Misses 334 313 -21 see 14 files with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks OK.
Not an expert on platta pipelines, but could consider if you still want to separate development and production tags to reduce the odds of accidentally deploying a development version into production. In default platta pipelines this can be achieved using buildenv
parameter, which can have values like -dev
or -prod
. Normally a build stores the generated (random) image tag into Azure variable LATEST_IMAGE_TAG.
Deployment jobs, without a buildenv parameter set, will deploy the image based on what is stored in LATEST_IMAGE_TAG. If buildenv is set for both the build and deployment, for example buildenv: -dev
, then the build will update both LATEST_IMAGE_TAG
and LATEST_IMAGE_TAG_DEV
and the deploy job will use LATEST_IMAGE_TAG_DEV
when deploying.
azure-pipelines-build-release.yml
Outdated
# Drupal example: azure-pipelines-drupal-release.yml | ||
template: azure-pipelines-build-tiedonohjaus-api-release-staging.yml@tiedonohjaus-pipelines | ||
# parameters: | ||
#imagetag: ${{ parameters.imagetag }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well ok, minor nitpick from unix/linux perspective would be good to have newlines at the end of the yaml files.
By the way, doesn't matter with this one, but apparently sonarflow can't be used on PR's coming from forks, so for future code commits it would be preferable if PR's are made directly from this repo instead of forks. |
Added newlines to my fork, pipelines are just a base that can be modified as needed by the project. |
Description
Triggering pipelines for triggering azure build pipelines for main changes and releases.
Related Issue(s)
DEV-XXX
Motivation and Context
To allow automated pipeline triggers when code changes.
How Has This Been Tested?
Tested that pipelines start
Additional Notes
Screenshots / Videos