My question is about Azure DevOps build pipeline. I wanted my build to automatically triggered when commit changes. So I include the files using Folder/**/* which any files under the folder including under subfolder. But when I commit changes in one of the file, my build does not triggered. But it worked when I use Folder/* instead. Can anyone explain what is the differences?
I think this could be by design. For the path filter, it could only recognize /* and not /**/*.
For paths:
You may include * as the final character, but it doesn't do anything
differently from specifying the directory name by itself.
You may not include * in the middle of a path filter, and you may not
use ?.
This is stated in the Wildcards of this document.
This is now possible as it is written here Support for wild cards in path filters
Wild cards can be used when specifying inclusion and exclusion branches for CI or PR triggers in a pipeline YAML file. However, they cannot be used when specifying path filters. For instance, you cannot include all paths that match src/app//myapp*. This has been pointed out as an inconvenience by several customers. This update fills this gap. Now, you can use wild card characters (, *, or ?) when specifying path filters.
The documentation is still not updated but you can use Folder/**/* in path filter.
Related
This is the check name in Github using Github Actions.
It contains the workflow name + job id + step name + on condition.
Is it possible to make it shorter, as we have with apps? SonarCloud, for example, only has a single name.
Removing the name parameter only makes it worse since github will use the full filename (plus path) instead of a single friendly name.
You can customise that by defining run-name on top level of your workflow.
run-name: "SonarCloud Code Analysis"
You can read about it in docs here
Occasionally in our codebase we need to use an //eslint-disable to bypass a styleguide rule on a line. I would like to somehow automatically add a comment on each new instance of that in PRs, requiring the developer to explain why they bypassed the styleguide.
I've found this question referencing how to create a comment programmatically, but what I'm not sure how to do is identify the new code and parse it for a certain piece of text, then add comments on those particular lines where the text was found.
This is one of the approaches to ingest scripts & achieve what you want, wherein Expected outcome is:
On every pull request, a pre build validation pipeline kicks off & adds comments on the PR.
Create a script (powershell/python/bash) with following logic:
Find file names in the given branch which contains //eslint-disable
In the files above (1.), get the location/line number of //eslint-disable
Foreach file.LineNumber (wrote like that just for representation): add comment on file.LineNumber using Pull Request Threads API. See line parameter
Create a pipeline containing above script & add that pipeline as build validation or if you have an existing build validation process, add these scripts as tasks in that pipeline.
Hope this helps :)
With Azure DevOps release pipeline I'm planning to tag my brach Automatically by using the below extension which was created by Micheal Barry Tag\Branch Git on Release. See the below image:
I'm a bit wondering how to customize Tag name as UAT_$(date:yyyyMMdd)$(Rev:.r). Since this has limited documentation, this is how I try to add(See below)
How can I achieve this? Also, I'm more interested in how to fill these advanced options for this extension.
The $(date:yyyyMMdd)$(Rev:.r) is only supported in BuildNumber (Options=>Build Number Format) and ReleaseNumber (Options=>Release Name format). So if you put $(date:yyyyMMdd)$(Rev:.r) directly in Static Tag Name, the task can't evaluate its value.
Here're several directions to do what you want:
Use $(date:yyyyMMdd)$(Rev:.r) as release name format.
Then use UAT_$(Release.ReleaseName) in Static Tag Name input.
The result:
PS: If you set build pipeline as release pipeline's artifact source, you can also use $(Build.BuildNumber)/$(Build.DefinitionName) in your Release name format.
2.If you prefer to use Release-$(date:yyyyMMdd)$(Rev:.r) as release name format. Now since what you want is UAT_xxx, you need to use the Regex option:
Assuming your release name's instance is Release-20200518.5, now the tag would be UAT_20200518.5 if you configure the task following my inputs above.
In addition:
When release name format is $(date:yyyyMMdd)$(Rev:.r), you releases would be:
You can choose to use the Static Tag Name, check #1 above.
And when the name format is Release-$(date:yyyyMMdd)$(Rev:.r), you releases would be:
You should use regex option in that third-party task, check #2 above. About what is Regex see here, also there's many documents/blogs online about Regex topic...
You are using the wrong task in your pipeline. Would suggest using the git tag task, it works just fine to me and you can use your naming in the tag field
Git Tag Task
I find this extension much easier to setup and its satisfying our needs. So basically my git tag=assembly version. I am doing this every time we have a release on production environment(change assemblyInfo information and store that in Variable in the build definition). There are set of tasks on the marketplace to allow read from asemblyInfo and write to it. For the git tag task i just use the previously set Tag variable which basically is incremented by one every new release. You can check more in the pictures bellow
So i am actually just adding simple tag to mirror my assemblyVersion but in the tag message i am also adding my build informations that looks like this $(build.buildNumber)-$(Tag)
If you want to have a deeper look into azure devops predefined variables you can do that here Use predefined variables
We have two separate builds configured in TeamCity against TFS with the following triggers (listed below).
Build 1:
+:Folder1/Folder2/Folder3/FilePrefix\*\*
+:Source/\*\*
+:Tests/\*\*
Build 2:
+:Folder1/Folder2/\*\*
-:Folder1/Folder2/Folder3/FilePrefix\*\*
-:Tests/\*\*
-:Source/\*\*
If we make a change to a file in Folder1/Folder2/Folder3/FilePrefix we are finding that BOTH builds trigger. The documentation states:
For each file in a change the most specific rule is found (the rule
matching the longest file path). The build is triggered if there is at
least one file with a matching "include" rule or a file with no
matching rules.
Doesn't this mean that only the most specific rule takes precedence? Why isn't Build 2 excluding this file because of the -:Folder1/Folder2/Folder3/FilePrefix**? It seems like the +:Folder1/Folder2/** is overriding the ignore rule.
I ran into this a few weeks ago and found that we had to specify the final wildcard as a '.' instead of a '*' for negation statements.
So your trigger rules for build2 would end up looking like:
+:Folder1/Folder2/\*\.
-:Folder1/Folder2/Folder3/FilePrefix\*\.
-:Tests/\*\.
-:Source/\*\.
For example, instead of writing the following:
element * .../my_branch_01/LATEST
element * .../base_branch/LATEST -mkbranch my_branch_01
I would want to write something like this:
MY_BRANCH=my_branch_01
element * .../%MY_BRANCH%/LATEST
element * .../base_branch/LATEST -mkbranch %MY_BRANCH%
Is this even possible? What is the correct syntax?
The only native way to do this in ClearCase is to use attribute within a config-spec.
According to the version selector rules, you can make a "selection by query" rule, based for instance on an attribute:
element * ...{MY_ATTRIBUTE_NAME=="aValue"}
would select the LATEST version on any branch with an attribute 'MY_ATTRIBUTE_NAME' with 'aValue' in it.
That mean you need to change the attribute value on the old branch, put it on the new branch, 'cleartool setcs' your view again, and you should have a new content based on a new version selection.
Not very straight forward, but it could work, except for the mkbranch part (which needs a fixed name).
Regarding GeekCyclist's answer, a few comments:
The solution to include a common config spec can work for Base ClearCase solution, but:
need to be in a share available by all concerned developer
the setcs is indeed necessary to Ccuses the view_server to flush its caches and reevaluate the current config spec, which is stored in file config_spec in the view storage directory. This includes:
Evaluating time rules with nonabsolute specifications (for example, now, Tuesday)
Reevaluating –config rules, possibly selecting different derived objects than previously
Re-reading files named in include rules
all the other developers need to be notified when the common included config spec file changes (there is no native notification included in ClearCase)
If you need to have one "environment" (i.e. one "view" or workspace) with a variable content (depending on a different branch), you need to define a symbolic link (or a windows subst) pointing to different views (each with their own config spec)
That way, you only have to change the link (or the path subst'ed) in order to change the config spec associated with a given fixed path.
It's been a while since I worked in ClearCase (we switched to Subversion), but if I recall correctly there is no way to do this native to ClearCase.
You could use or write a script generator that would create your spec file and then include that in the actual spec:
element * CHECKEDOUT
include scripted_file_output
Then run
cleartool setcs -current
The problem with this approach is that I believe the include spec would need to be regenerated and the cleartool setcs run whenever you change the value of MY_BRANCH.