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/\*\.
Related
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 :)
I am attempting to remove all references of a managed package that is going to be uninstalled that spans throughout code base in VS Code
I have using a query to find the field permissions but am wondering if there is a way to search for the reference outside of specifying the exact field name compared to the field containing only "agf" since they are all using it.
Below is the search query:
<fieldPermissions>
<editable>false</editable>
<field>User.agf_Certified_Product_Owner__c</field>
<readable>false</readable>
</fieldPermissions>
In the field, I want to be able to find and delete the 5 associated lines from multiple files if they match "agf" in any combination. Something like the below:
<fieldPermissions>
<editable>false</editable>
<field>agf</field>
<readable>false</readable>
</fieldPermissions>
With any combination of agf in the field, delete all from any file it appears in.
Not an answer but too long for a comment
You don't have to? Profiles/perm sets don't block package's delete. Probably neither do reports.
You'd use your time better by searching for all instances of agf__ (that's with double underscore), should find fields, objects... used in classes, flows, page layouts etc. And search for agf. (with dot) should find all instances where your Apex code calls their classes marked as global.
Alternatively Apex / VF pages with dependencies on package will have it listed in their "meta.xml", for example
<?xml version="1.0" encoding="UTF-8"?>
<ApexClass xmlns="http://soap.sforce.com/2006/04/metadata">
<apiVersion>54.0</apiVersion>
<packageVersions>
<majorNumber>236</majorNumber>
<minorNumber>1</minorNumber>
<namespace>SBQQ</namespace>
</packageVersions>
<status>Active</status>
</ApexClass>
Last but not least - why not just spawn a dev sandbox and attempt the delete there? If it succeeds - great. If not - it'll list the dependencies that blocked the delete. It'll be "the real thing", it'll smite you even if your VSCode project doesn't contain all flows, layouts and thus could lull you into false sense of security. I'd seriously do it in sandbox and then run all tests for good measure, just in case there are some dynamic soql queries that don't count as hard, delete-blocking references.
After delete's done - fetch Profiles / Permsets from this org and the field references will be gone from the xml.
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.
the rule is
"//Reference[matches(#literal, \"^\$[^!]+\") and ./preceding-sibling::Text and ./following-sibling::Text]"
for your convenient I will provide the project and you can mvn-test it.
the whole project is at https://github.com/XenoAmess/p3c/tree/1605f4d1b9c6a505074be5328953af26f578e190/p3c-pmd
the Rule class is com.alibaba.p3c.pmd.lang.vm.rule.other.UseQuietReferenceNotationRule
I tried to look through your update log, and found nothing related.
Thanks for help.
That's a side-effect of fixing https://github.com/pmd/pmd/issues/1923. It has been fixed by using real/full name in the rule context (see https://github.com/pmd/pmd/pull/1982). In unit tests, the file name used is "n/a", which is now interpreted as the file "a" in directory "n". RuleContext::getSourceCodeFilename returns just the filename and not the full path. To retrieve the full path RuleContext::getSourceCodeFile can be used.
Your rule UseQuietReferenceNotationRule checks the filename (UseQuietReferenceNotationRule.java:65) which is now not "n/a" anymore in the unit tests but "a". You can "fix" the unit test by simply changing UT_FILE_NAME to "a" (see UseQuietReferenceNotationRule.java:45).
Alternatively you can change the rule to use ctx.getSourceCodeFile().toString() to recover the full pathname in UseQuietReferenceNotationRule.java:62. Although the file doesn't exist, it still points to "n/a".
An alternative for checking the path names in the rule itself might be File exclusion/inclusion patterns.
Also, contributions on https://github.com/pmd/pmd are welcome if you think the rules make sense for a wider audience.
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.