So, i have a public project that allows other people in my organization to open issues. I would like labels applied to each issue when it is opened. I have tried the /label method and that only works when the person opens the issue is a part of the project. It seems that Gitlab does not allow this as per this issue: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/73710
So, to get around this, I have set up a webhook that triggers a pipeline, parses some text at the end of the issue description (like ISS001)and then uses the Issues API to set the labels.
I have two questions that I can't seem to find a concrete answer to.
In the Webhook payload, does any of that information tell you what template was used? Looking through the payload, I cannot see any indication of that... which is why I am parsing the text at the bottom. In the object_attributes portion of the payload I see:
"id": <What is this?>,
"iid": <Issue Id>,
iid is the issue id, but what is id? I can't find that anywhere.
Is there a way to configure the cicd pipeline to only trigger on issue CREATE.. not update, close, reopen? I have it set as:
only:
- trigger
So no other actions trigger the pipeline but there are a TON of superfluous pipeline runs.
Thank you.
Related
I am triggering a Pipeline from another Pipeline over REST API, which works fine but one thing is annoying me.
I could not find a way to display with queued Pipeline original Commit Message of the Triggering pipeline.
There is a build in variable '$(Build.SourceVersionMessage)' which contains the information I need but I could not find a way to pass this information to triggered workflow so it can be displayed.
Following fields existing the REST API, I though the correct field would be 'triggerInfo' but that didn't changed anything in displayed build message.
Any idea how can I transfer this information and display it?
I currently have a task that I intend to run only once when a PR is created. Any pipeline runs due to new commits should not trigger the task. I was wondering if there is a way to detect the runs triggered by changes to code in the PR? When I use the predefined variable $(Build.Reason) I get back PullRequest for both builds(One triggered when PR is created and other when updates are made to PR).
This is what I have in my pipeline and I have enabled build validation for my pipeline.
trigger:
- master
pr:
- master
I don't think there's a way to differentiate the "PR is created" and "PR is updated" build reasons based only on the predefined variables.
However, you can choose a different route depending on what this task you should only run once is. If it is something that can be wrapped into a service with a public endpoint, you can try leveraging the Webhooks.
So, if this is an option for you, try the following:
wrap the functionality required to run only on the PR creation into the service with the public endpoint
create a webhook, choose "Pull request created" event type and enter the public URL of your service
As a result, your build logic won't branch depending on the build reason, and that specific action will be run by the webhook.
I understand it all sounds like a hack and unnecessary complexity, but it's up to you to decide whether it fits your case. At least, this is possible technically.
This seems very niche but I have a working system that I would like to simply add to.
Currently, I've a command in a game I've written call a simple Zapier url. Lets say, https://zapier.com/xxxxxxxx?name=me&message=hello%20there&location=location.
When called, it posts the name, location, and message to a discord channel. I would like this to e extended.
What I would, ideally, need is to figure out how Zapier could create a new task in Phabricator manifest titled something like "Bug 231" with the context including name, location, and message, and put it on a projects workboard under a specific category and assign users to it.
I feel like this is possible but cannot figure out the proper syntax.
Zapier itself can perform extra actions out-of-the-box with "Multi-Step zaps". You could add an action after your Discord step to create a Phabricator task.
But, it looks like there's no Phabricator integration on Zapier. If Phabricator has a web API that allows for task creation, you can plug that into Zapier via either:
a "Webhooks by Zapier" step that makes the request
a "Code by Zapier" step if extra processing is needed
a custom Zapier integration w/ Phabricator if you anticipate wanting more actions than "Create Task"
For those seeking similar, I found a way that worked for me :
1- I used https://www.freeformatter.com/json-formatter.html#ad-output to help me with Phabricator's interesting requirements.
2- I went in to conduit / maniphest.edit and used this JSON in the first field to get my desired curl output : [{"type":"title", "value":"test title"},{"type":"description", "value":"This is the description."},{"type":"projects.set", "value":["PHID-PROJ-4dufje6oug3liomahstg"]}]
I took the curl it gave me and put it in here : https://curl.trillworks.com to turn it in to python.
I put the python in to the Zapier python module, replacing text in several places with the variables that Zapier provides.
Issue
Trying to get the Gmail API to send only new messages to Cloud Pub/Sub by using the Gmail APIs Watch function but when setting the labelIds in order to filter to just INBOX, i am still notified of all changes, files sent, drafts etc.
I've looked online and can see that there are people that are experiencing this issue and there is even a bug out for it https://issuetracker.google.com/issues/36759803.
But i find it kind of odd that the entire feature of filtering just doesn't work and its been an issue for 5 years according to the bug report. Makes me think its just me that is doing something wrong. Would be cool to hear from anyone that has got this to work.
Where im at
I'm using the Gmail API, trying to get my Gmail account to publish messages to Cloud Pub/Sub. I've managed to do this however im trying to filter what i get notifications for to just new messages. This is where i have a problem.
According to this Gmail API documentation, it appears all i have to call is the code below and that should be that. I will add however, that im calling the Kotlin equivalent, but i don't think this should matter.
request = {
'labelIds': ['INBOX'],
'topicName': 'projects/myproject/topics/mytopic'
}
gmail.users().watch(userId='me', body=request).execute()
What im calling:
val request = WatchRequest().apply {
labelIds = listOf("INBOX")
topicName = "projects/myproject/topics/mytopic"
}
gmail.users().watch("me", request).execute()
Other things ive tried
I have tried adding labelFilterAction = Include and other variations but they all seem to be ignored.
After trying the ideas listed by ziganotschka, I'm more confident that the issue is not related to specific client libraries.
I managed to speak to someone at Google who in turn contacted the G-mail API team. They said they were aware that this is an issue, that it has been an issue since 2015 and was most likely caused by a change they made back then.
A ticket is still open, but doesn't look like it will be fixed.
Perform the following trouble-shooting actions
Provide a request body including labelIds, labelFilterAction AND topicName as specified here
Try the label "UNREAD" instead of "INBOX"
To discart Kotlin implementation related issues, test your request in a programming language that allows you to pass the request as a JSON body in exactly the same way as specified in the documentation.
I have the pull request id of all the pull requests in a public repository. I was wondering if I could use this information to get the commit level information using Github api? I understand that this is fairly simple if the issue number is known. Unfortunately, i do not have the issue number for the pull requests.
The best you can do is to search all issues based on repo name,type (:pr) and date of creation. Using the api, the above search would translate into - https://api.github.com/search/issues?q=repo:km-Poonacha/testissues+type:pr+created:2017-06-16. I think one of the problems of using the id is that each pullrequest has an issue id and a different pullrequest id.
GitHub does not have any endpoints that allow you to filter using PullRequestevent ID. So, I guess the method you used by filtering based on type and date of creation is the best you can do for now.