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
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 :)
can i restrict barnch name in our pattern so all developers can follow predefined format of branch name?
I want to apply branch name pattern globally so when developer create branch and submit code , then branch name must first validate with our defined naming convention, if succeeded then it will pass to remote other show error message in local system
Thanks
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
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.
Situation is:
Currently, I have a repository name phimpme-iOS. I want to capitalize the first letter of the repository, Phimpme-iOS.
When I change the name in Settings > Options > Repository Name, it cannot be changed and it is showing -
The repository Phimpme-iOS already exists on this account
User names and repository names are case-insensitive at Github: phimpme-iOS is the same as Phimpme-iOS; that is, from Github PoV you're trying to rename the repo to an equivalent name.
Try a completely different name — xxx, for example — and then rename it once more to Phimpme-iOS.
Rename your repository to something completely different (e.g. "foo") and then name it back to the original name with the desired capitalization.