We are currently running a linter for each of our CI builds within GitHub PRs. This linter, though, requires a dbt manifest.json which we can only build when the full dbt schemas are available in the PR schema.
We currently need to manually re-trigger the action workflow after dbt Cloud Slim CI is finished, since we have the on trigger as follows:
on:
pull_request:
branches:
- main
types: [opened, reopened, ready_for_review, synchronize]
And, as mentioned, the manifest.json is not yet built at the moment when the PR is e.g. opened.
Is there any way that we can trigger the workflow only once the Slim CI job (that is triggered by dbt Cloud) is actually completed, and therefore the manifest.json already built?
I've come across on.check_run and on.status for Events that trigger workflows (see GH docs), but not sure whether these can be used since, as specified in the docs: "Note: This event will only trigger a workflow run if the workflow file is on the default branch."
Related
I want to deploy my app by using secrets in a "Production" environment.
I create a GitHub Action workflow for deployment. The workflow is triggered by push, and pull_request events on main branch. The workflow has a check_deploy job that uses Production environment secrets for check the eligibility for deployment.
When I create a pull request to main branch, the workflow is triggered and run. The job check_deploy should run successfully.
Because the job check_deploy uses Production, it is added to the deployment history, and I do not expect this behavior.
GitHub repository is the demo.
And this is my question "How to use secrets in the Github Environment without adding to the deployment history of this environment?"
In our Azure DevOps Server 2019 we want to trigger a build pipeline on completion of another build pipeline. The triggered build should use the same source branch the triggering build used.
According to the documentation this does not work with classic builds or the classic trigger definition, but in the YAML definition for the triggered build:
build.yaml:
# define triggering build as resource
resources:
pipelines:
- pipeline: ResourceName
source: TriggeringBuildPipelineName
trigger:
branches:
- '*'
# another ci build trigger
trigger:
branches:
include:
- '*'
paths:
include:
- SubFoldder
pool:
name: Default
When creating the pipeline like this, the trigger element under the pipeline resource gets underlined and the editor states that trigger is not expected inside a pipeline.
When saving the definition and trying to run it, it fails with this error:
/SubFolder/build.yaml (Line: 6, Col: 7): Unexpected value 'trigger'
(where "line 6" is the trigger line in the resources definition).
So my question is: How to correctly declare a trigger that starts a build pipeline on completion of another build pipeline, using the same source branch? Since the linked documentation actually explains this, the question rather is: what did I miss, why is trigger unexpected at this point?
Update: I just found this. So it seems one of the main features that they promised to have and documented as working, one of the main features we switched to DevOps for, is not even implemented, yet. :(
Updates are made every few weeks to the cloud-hosted version, Azure DevOps Services. These updates are then rolled up and made available through quarterly updates to the on-premises Azure DevOps Server and TFS.So, all features are release in Azure DevOps Service first.
A timeline of feature released and those planned in the feature release can be found at here-- Azure DevOps Feature Timeline
You could choose to directly use cloud version Azure DevOps Service instead or monitor latest update on above Feature Timeline with Azure DevOps Server. Sorry for any inconvenience.
I am confused why the following 2 things happen:
When I push some commits to my feature_foo branch, 2 workflows (builds) are run: the primary workflow against the latest commit, and deploy workflow against my last PR, both on feature_foo. I expected only the primary workflow to be run as I haven't issued a PR yet
2 identical email notifications are sent to me from artifacts+\<my-bitrise-project-id\>#bitrise.io within the same minute. I understand that a PR can lead to two builds (as a PR is technically a push), but doubt that is the issue here as I've not created a PR yet.
Here is my current bitrise.yml trigger map:
trigger_map:
- push_branch: "*"
workflow: primary
- pull_request_source_branch: "*"
pull_request_target_branch: feature
workflow: deployment-staging
- tag: "v*.*.*"
workflow: deployment-production
By the way, this is my desired 3-workflow setup:
Run integration tests (primary workflow) on 2 occasions:
Code push to * (any branch)
Pull requests to feature branch (when the PR is created i.e. pre-merged state so contributors can preview the potential effect of their proposed changes)
Run deployment (deploy workflow) to staging when PRs from * to feature branch are merged
Run deployment (deploy workflow) to production when tags v*.*.* are pushed
What is the correct bitrise.yml config to achieve this? The docs do not indicate how we can differentiate PRs by state (issued vs merged). I want to deploy only after the code has been reviewed.
Thanks
If you open the PR will that trigger another build? Are you sure the PR isn't opened yet?
To answer
I want to deploy only after the code has been reviewed.
I guess you mean when the PR is reviewed and merged into the target branch e.g. into master.
For that you can use a config like this: https://devcenter.bitrise.io/builds/triggering-builds/trigger-map/#dont-start-two-builds-for-pull-requests-from-the-same-repository
trigger_map:
- push_branch: master
workflow: deploy
- pull_request_target_branch: "*"
workflow: primary
This will run a build using the workflow called primary when you open the PR and every time you update the PR. Typically you want to run some automated tests in this case, in the primary workflow (unit/ui tests, linters and/or doing maybe a test build).
Then when you merge the PR (in this case into the master branch) it'll trigger a build using the deploy workflow (as technically a merge generates a commit/push event).
I hope this helps, let me know if you have any questions!
Viktor's answer is sufficient, but I wanted to add some more findings that might be relevant to someone else:
When I push some commits to my feature_foo branch, 2 workflows (builds) are run: the primary workflow against the latest commit, and deploy workflow against my last PR, both on feature_foo
I believe this happened because I had an open PR and pushed additional commits to the source branch of that PR. Based on my trigger map (shared above on the OP) at that time, it would run a deploy-staging workflow. The trigger map shared by Viktor makes more sense for my use case
2 identical email notifications are sent to me from artifacts+\#bitrise.io within the same minute
Turns out Bitrise sends both a signed and an unsigned APK (for whatever) in two separate emails
We have an app (let’s call it the main repo) on GitLab CE, that has a production build & deploy pipeline, which is only triggered when a tag is deployed. This is achieved in .gitlab-ci.yml via:
only:
- /^v.*$/
except:
- branches
We also have two other (let’s call them side) repositories (e.g. translations and utils). What I’d like to achieve is to rerun the latest (semver) tag’s pipeline of main, when either of those other side repositories’ master branches receives a push. A small detail is that one of the repositories is on GitHub, but I’d be happy to get them working on GitLab first and then work from there.
I presume I’d need to use the GitLab API to trigger the pipeline. What I’ve currently set up for the side repo on GitLab is a webhook integration for push events:
https://gitlab.com/api/v4/projects/{{ID}}/ref/master/trigger/pipeline?token={{TOKEN}}, where ID is the ID of the main project and TOKEN a deploy token for it.
However, this will only trigger a master pipeline for our main repo. How could I get this to (also) rerun the latest tag’s pipeline (or the latest tagged pipeline)?
Secondly, how would I go about triggering this on GitHub?
Either you can create new pipeline specifying ref which can be branches or tags, so in this case you need to know the exact tag value https://docs.gitlab.com/ee/api/pipelines.html#create-a-new-pipeline
Or you can retry already the executed pipeline by providing its id which you can get from https://docs.gitlab.com/ee/api/pipelines.html#list-project-pipelines by sorting by id and filtering by ref but it'll give you the last pipeline with a tag /^v.*$/ which may not match with the specific version you need.
I created a webhook in jenkins and connected it to github webhook & services.
I came upon the following issue When the build is completed, the pom.xml is updated with the version and tag . This triggers build job again and its goes into a loop until, I manually stop it .
I have set the build trigger to "Build when a change is pushed to GitHub"
I would like to find out how to stop the build trigger when the pom.xml is updated only as part of the build?
In the source code management job configuration section add Additional Behaviors and select Polling ignores commits from certain users and provide the user name your Jenkins job uses to checkin pom.xml. You can also use Polling ignores commits in certain paths and provide path to pom.xml.
I'd suggest not committing the version update to the master branch but create a separate tag every time. Something like this:
v1 v2 v3
/ / /
--A----B----C (master)
I got this approach from Real-World Strategies for Continuous Delivery with Maven and Jenkins video (corresponding slides) - it contains other tips on setting up build pipelines with Maven as well.