Skipping deployment with the npm provider because this branch is not permitted to deploy - deployment

I am trying to build and deploy my npm package to npm registry automatically upon push to master branch.
Here is my .travis.yml file content:
language: node_js
node_js:
- '0.11'
- '0.10'
deploy:
provider: npm
api_key:
secure: XXX
on:
tags: true
branch: master
The build runs successfully, but the deployment fails with message:
Skipping deployment with the npm provider because this branch is not permitted to deploy.
Why is that? I tried both without specifying any branch and specifying 'master' branch explicitly.
Here is the travis build status in details.
Any suggestion/clue to solve this issue is appreciated. Thanks in advance.

With tags: true you specify, that only tagged commits will be deployed. If I'm not mistaken, Travis CI does not explicitly check on which branch such a commit is on. So either specify tags: true, then make a tagged commit OR specify branch: master and commit to this branch to trigger a deployment.
But using both statements won't work.
You can find a note in the Travis CI documentation (similar for GitHub) stating:
tags: When set to true, the application is deployed when a tag is applied to the commit. (Due to a known issue, you should also set all_branches: true.)
So the correct answer is to specify either a branch OR use tags: true and all_branches: true.
If you're using GitHub:
Please note that deploying GitHub Releases works only for tags, not for branches.

Related

is there any way to select branches from multiple repositories in CI build

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:

How do I get Azure Pipeline to set Build.SourceBranch to do the tag

When I do npm version patch && git push I want it to run a step based on a condition.
trigger:
branches:
include:
- master
tags:
include:
- '*'
...
steps:
- bash: |
npm publish
displayName: 'npm publish'
condition: startsWith(variables['Build.SourceBranch'], 'refs/tags/')
But I always get refs/heads/master for source branch.
UPDATE:
git push does not normally push tags by default.
git push --tags or git push --follow-tags will push the necessary tags. To ensure that this occurs by default
git config --global push.followtags true
However, this does not fully work either, because if you push master with tag the refs/heads/master still becomes Build.SourceBranch
So I have to push the tag specifically and ensure that the build triggers, but I'd rather avoid that.
I'd also like to avoid creating a separate pipeline with a different trigger (namely the tags) to do the build.
From the YAML documentation, it seems like that is only used for manual or scheduled builds, not a CI trigger.
tags: [ string ] # list of tags required on the pipeline to pickup
default artifacts, optional; Used only for manual or scheduled
triggers
I imagine you would only get it if you were doing something like the below to manually run a tag:
For most my cases specifically, I let the CI build run have a step that manages the tag creation rather than pushing a new tag.

Determining the triggering branch with a multi-repo CI setup in Azure Devops

In ADO, you can create a "repository resource" per this documentation. The "trigger" section allows you to define a CI trigger for any Azure repo in your space. Therefore, given the following config:
Repos:
AzureRepo1 - Contains project files that should be built
AzureRepo2 - Contains pipeline file 'pipeline.yml'
resources:
repositories:
- repository: "Azure_Repo_1"
type: git
name: AzureRepo1
ref: development
trigger:
branches:
include:
- development
- staging
- production
pool:
vmImage: 'windows-latest'
jobs:
- template: Template.yml
parameters:
service: "development"
run_tests: true
When I make a change to AzureRepo1, the pipeline triggers. At runtime, how would I determine which branch ("production", "staging", or "development") of the target repo (AzureRepo1) triggered the build? Ideally, the "service" parameter being fed into the example template would dynamically reflect which branch triggered the build.
Note: "Build.SourceBranch" and "Build.SourceBranchName" seem to pull the branch from the repo that hosts the YML file (in this case, AzureRepo2).
I was wrong. These function as intended. Use the below solution.
According to documentation here:
When an update to one of the repositories triggers a pipeline, then the following variables are set based on triggering repository:
Build.Repository.ID
Build.Repository.Name
Build.Repository.Provider
Build.Repository.Uri
Build.SourceBranch
Build.SourceBranchName
Build.SourceVersion
Build.SourceVersionMessage
For the triggering repository, the commit that triggered the pipeline determines the version of the code that is checked out. For other repositories, the ref defined in the YAML for that repository resource determines the default version that is checked out.
If triggers happens on AzureRepos1 you should have correct branch name in Build.SourceBranchName

Push Build status to GitHub

I'd like to push the build status automatically from Azure Devops to the github repository, so that pull requests can check for a build success before they can be merged.
I realise this can be done writing some custom code and calling the github status api, but there is a checkbox for it in the edit pipeline stage. It doesn't seem to work with Github though. See this image .
Other build tools like Bamboo have an out of the box plugin for doing this.
You need to define branch policy. You can read about this on my blog. You need to selected existing pipeline here in GitHub settings:
and then when you make PR you will get this:
You need to correctly define trigger options in your yaml file. For isntance:
this will run for all non master branch (with each commit pushed to GitHub pipeline will run)
for each merge to master will trigger pipeline too
trigger:
branches:
include:
- '*'
exclude:
- master
pr:
branches:
include:
- master
paths:
include:
- gated-checkin/*
exclude:
- gated-checkin/azure-pipelines.yml

How to deploy base on multiple branch?

I am using appveyor to publish packages to nuget, I would like to do the publish if the branch is either master or dev, my current settings is
deploy:
provider: NuGet
on:
branch: master
How can I add dev branch?
I solved this problem by using regex, here is what i got
on:
branch: /^(master|dev)$/