My pipeline name is set as
name: $(Date:yyyyMMdd)$(Rev:.r)
this works but Azure Pipelines still includes the commit message in my pipeline name. For example, the pipelines UI shows:
#20200422.2 The commit message
is there a way to get Azure Pipelines to just use the name I specified?
Thanks.
is there a way to get Azure Pipelines to just use the name I specified?
Sorry for any inconvenience.
This behavior is by designed and is not a bug. I do not believe there is a way to set Azure Pipelines name without submit message.
Including the submit message in the name of the pipeline helps us find the cause of the pipeline failure faster.
For example:
Just like above build history, We could directly judge the cause of the failed pipeline by the same submit information, not from the code update, more from the task settings and pipeline settings.
On the other hand, We could judge that the pipeline failure may be due to the update of the code according to the different submit information. Then we check the submit record through the submitted history, and we will quickly know which code we have modified to cause the build to fail, which provides great convenience.
This is especially important for those pipelines that enable CI.(
Enable continuous integration).
Hope this helps.
Related
I want to have my build pipeline configured such a way that when ever my pipeline fails there is a bug created for the same. I cannot find an option to select this configuration for a particular branch. Can someone help me with this.
I want to create a bug whenever my build pipeline fails in azure devops. And i want to have it configured for a particular branch
There is an option Create a work item on failure on the pipeline Options tab.
If the build pipeline fails, it can automatically create a work item to track getting the problem fixed.
But we could not configurate it for a particular branch for this option, but we could create a new pipeline with trigger filter Branch specification:
In this case, only the particular branch build failed, it will create a bug.
What I'm thinking about is to have a step in the pipeline to generate a full-blown pipeline to run afterwards.
Apparently this particular thing is not there yet (feature requests here, here). But maybe somebody has some fresh thoughts on workarounds?
Not really. It's a pain that's just a fact of life when working with YAML pipelines. It's especially annoying when trying to work through runtime vs compile time variable resolution issues.
Commit, run, commit, run, commit, run, over and over.
For the dynamic work you could set up a repo with one dummy yaml file and a pipeline registration that targets this yaml file.
From a static pipeline that is responsible for kicking off a dynamic pipeline you then execute two steps:
Create a fresh branch of that "dynamic" yaml file and commit the required dynamic workload
Not sure about branch limits though. You could also decide to reuse a branch.
Kick off this "dynamic" pipeline through az devops cli using the static pipeline's access token
Also see the following documentation:
https://learn.microsoft.com/en-us/azure/devops/cli/azure-devops-cli-in-yaml?view=azure-devops
I'm doing Visual Studio builds on a self hosted agent, which are currently being triggered by the Continuous Integration setting in an Azure Devops pipeline.
When a build completes, it shows: Triggered by Microsoft.VisualStudio.Services.TFS
It also shows the repository, branch and revision number.
However, it is expected it would show Triggered by , If not showing the correct Azure Devops user, at least showing the Subversion user name, that would be something.
There was an expectation it would be possible to send email notifications to the user of the commit. (Not fool proof that they caused the problem, but the most convenient way to give the responsibility to somebody to make sure any build error gets resolved)
Does anybody know if a solution exists?
In both Classic and yaml pipelines, you can specify a condition for a pipeline step. If you want it to run when the pipeline fails, it will be condition: failed() (in yaml), or Control Options -> Run this task -> Only when a previous task has failed (in Classic). Alternativel, you can check Agent.JobStatus variable.
there's no predefined variable for current committer, but you can easily determine the last commit's author by using svn command, then log it. (any other version control system will have its own CLI that should allow it).
In yaml, it could look like this (using git instead of svn):
steps:
... (your build)
- bash: |
author=`git log -1 --pretty=format:'%ae'` # get last commit author from git
echo "last commiter: $author"
# TODO: send email or other kind of notification
condition: failed()
In classic one:
You are using wrong tool for you task. CI build will be triggered after changes was committed to branch. In that case it is not possible to fix those changes. As a result you will have history where a lot of revisions are not stable.
It might be more suitable for you to use PR policy build. It is designed to validate incoming changes so target branch will be always stable and ready to some deploy. In this case, policy build will be triggered by PR creator so he will be informed about it's result. That can be configured in personal notification settings.
In the end I couldn't Continuous Integration triggers to reliably work. They would always stop working after a short time. I'm surprised I have ran into so many issues with this, but I guess it just isn't that well supported.
Instead, now, I am queue the build via an svn post-commit hook which uses the azure devops REST API.
the REST API has setting, requestedFor":{"id":""}, where you can add the user id (which I also needed a rest api command to find)
A lot of messing around to get to this point, for a feature I expected to 'just work', hopefully this keeps working
With the classic build pipelines and classic triggers, it was easy enough to track builds that were triggered by completion of other builds by just polling for builds requested by the same user.
Now, with resource triggers, the requested by property switching to the build service account instead of the original author of the triggering commit.
I have been going through the documentation to try and find another way to see triggered builds from the original build ID but have not found anything.
There is an "Associated Pipelines" tab on the build summary page that at least has the pipelines containing the triggered builds, but I cannot find anything to get that by API either.
According to your description, you can first call the REST API to get all the running build pipelines in the definition, and then use the powershell script to loop check the id in the parameter triggeredByBuild in the request body in the specific build so that you can see triggered builds from the original buildId.
Note: The id marked in the attachment is the original buildId that triggered another build pipeline.
I recently got to know Dockup and while I really love this kind of integration in Github, I am wondering if the same thing can be achieved in Gitlab, for free.
Basically, what I would like to achieve is:
On merge request, build tests and deploy in a dedicated environment which would use the name of the merge request
Send a message to a given slack about the environment or the failure of the build / tests in the pipeline with the related link of the pipeline
It seems that since Gitlab 11.6 it is possible to have Pipelines for merge requests but I don't really see how to get the information of the merge request or even who has submitted the merge request to use it for creating the dedicated deployment environment in my pipeline script?
How can I get that?
Note: It seems only a webhook can provide the information about the user and all the details.
Found the information I wanted in https://docs.gitlab.com/ee/ci/variables
CI_MERGE_REQUEST_TITLE
CI_MERGE_REQUEST_PROJECT_URL
GITLAB_USER_NAME
CI_MERGE_REQUEST_ASSIGNEES
Probably won't even need to create a webservice for the webhook since everything can be found in the environment variables when running the pipeline script, this is pretty awesome!