I am attempting to create GA4 analytics events by POST-ing to the URL with the same details as a web app:
curl -X POST "https://www.google-analytics.com/collect?v=2&tid=<MY_TID>&cid=<MY_CID>&t=event&en=someNonsense&ep.aParameter=value&z=1234567890" -H "Content-Type: text/plain;charset=UTF-8" -H "sec-fetch-mode: no-cors" -H "sec-fetch-site: cross-site" -H "sec-fetch-dest: empty" -H "pragma: no-cache" -H "cache-control: no-cache" -H "origin: http://localhost:5000" -H "content-length: 0" -H "accept-language: en-US,en;q=0.9" -H "accept-encoding: gzip, deflate, br" -H "user-agent: dummy"
All of these events show up perfectly in the realtime view, and if I add &_dbg=1 to the URL, these events and all their parameters show up consistently and reliably in the DebugView too.
I waited 48 hours and the events didn't show up. I did the following to try to bring things to life:
added all the event parameters as custom metrics
disabled the internal traffic filter which is active by default
dug through the settings and agreed to the "Data Processing Terms"
I then waited a further 48 hours and nothing has changed. Things seem to work just fine if I do them through a browser with firebase-analytics.js.
Does anyone have any idea what I've missed/broken?
Is Google doing some post processing on events to make sure they're coming from a real web page? I can mimic the HTTPS requests of the browser and the events still wont get recorded.
I can see my events showing up in realtime on my GA4 account. Perhaps you need to debug your events using the https://ga-dev-tools.web.app/ga4/event-builder/
I've managed to get things working.
It turns out GA4 will not log events unless they are part of a session. If I send a session_start event with ga_session_number and ga_session_id properties, any subsequent events will be properly recorded for the duration of the session.
I want to set up cronjobs in the same ubuntu 18 server but for different timezones.
For example, I wanted to send a notification to every UK user at 9 a.m. and the same notification should be triggered to US users at 9 a.m. according to their timezone.
I tried the implementation below but it is not working. Still those notifications are triggered in UTC timezones.
Is there any way to achieve this? 3rd party service is also fine.
CRON_TZ = 'Europe/London'
0 9 * * * curl --silent https://example.com/checkUk
CRON_TZ = 'America/New_York'
0 9 * * * curl --silent https://example.com/checkUs
If you want to set different timezone for your particular cronjob, execute crontab -e via ssh and add
TZ=America/New_York
before every cronjob.
Refer this SO Link which might help you .
Calling the REST-Api, I want to get a list of tasks with their corresponding summed tracked time grouped by their project. As an example, if I have the following time entries:
2h, Task1, ProjectA
1h, Task1, ProjectA
3h, Task2, ProjectB
30m, Task2, ProjectA
I would like to get the following report:
ProjectA
Task1, 3h
Task2, 30m
ProjectB
Task2, 3h
At the moment this is possible via the UI, but I could not find a way to do this by calling the API.
Does anyone know how this works?
Unfortunately there is no endpoint that would return data grouped that way without additional formatting on the client side.
If you're up for some data transformation on the client you can use for example:
GET workspaces/{workspaceId}/reports/summary
It will contain a section 'projectAndTotalTime' which will show summed time entry duration per project, and a section 'timeEntries' with individual entries that you can group/sort by project on the client.
With Clockify's new API this is possible, here an example with cURL:
curl --request POST \
--url https://reports.api.clockify.me/v1/workspaces/<YOUR WORKSPACE>/reports/summary \
--header 'content-type: application/json' \
--header 'x-api-key: <YOUR API KEY>' \
--data '{
"dateRangeStart": "2020-07-13T00:00:00.000Z",
"dateRangeEnd": "2020-08-13T23:59:59.000Z",
"summaryFilter": {"groups": ["PROJECT", "TASK"]},
"exportType": "JSON"
}'
You can even select different export types, see https://clockify.me/developers-api#tag-Reports.
I'm successfully able to use this to kick off a Jenkins Job:
curl -X POST "http://jenkins_srv:8080/job/MY_JOB/buildwithParameters?this=1&that=2" --user name:pass
I can also get the consoleText from this job using:
curl -X POST "http://jenkins_srv:8080/job/MY_JOB/lastBuild/consoleText"
However, this doesn't scale if I run multiple jobs back to back. I've noticed that the first curl command has a return that includes:
Location: http://jenkins_srv:8080/queue/item/123/
I'm assuming that 123 is the job queue id.
My question is, if I queue jobs 121, 122, & 123 back to back, what do I use to check the status of job queue item 122? Also, what do I use to determine the actual build id that eventually resulted from job queue item 122?
I chose Kdawg's answer, because it helped lead me in the direction that I needed. Thank you!
I'm also including my own answer, because the solution I implemented was different than Kdawg's answer, and I feel it will add value for other people.
First off, I'm new to Jenkins. So if I misspeak, please feel free to correct me. Second, I had a slight learning curve in that there is a difference between a Jenkins "queue item" and a Jenkins "build job". The instant that a "queue item" has been created, there is no "build job" ID, because no build job has started. Also, once a build job has started, the queue item has 5 minutes before it is deleted.
When I perform these tasks:
curl -X POST "http://jenkins_srv:8080/job/MY_JOB/buildwithParameters?this=1&that=2" --user name:pass
curl -X POST "http://jenkins_srv:8080/job/MY_JOB/buildwithParameters?this=1&that=2" --user name:pass
curl -X POST "http://jenkins_srv:8080/job/MY_JOB/buildwithParameters?this=1&that=2" --user name:pass
Jenkins will schedule 3 build jobs to be run in a queue. These will be "queue items". These "queue items" will have a "Queue ID". In the example given in my original question, lets suppose that these three curl commands create "queue items" with "Queue ID"s 121, 122, & 123.
Why is this important?
Because depending on the load of your Jenkins server, the item that was queued may or may not be run immediately. If it runs immediately, then Kdawg's answer is definitely correct. Running his commands:
curl -X GET http://jenkins_srv:8080/queue/item/121/api/json?pretty=true --user name:pass
curl -X GET http://jenkins_srv:8080/queue/item/122/api/json?pretty=true --user name:pass
curl -X GET http://jenkins_srv:8080/queue/item/123/api/json?pretty=true --user name:pass
This will get queue information about each "queue item", and in what returns, there is definitely a way to obtain a "build job" ID, if the build job has started. If a build job has not yet started, this information will be blank.
Here's the additional part that, I feel, adds value.
Once a build job has started, the information in Kdawg's answer will be populated in the response to the three curl -X GET commands. Also, by default, Jenkins is designed to scavenge (garbage collection, choose your own term) the "queue item"s every 5 minutes. So in other words, if all you have is a "queue item" ID and the 5 minute data retention window passes, then you need another mechanism in order to get a "build job" ID from a "queue item" ID.
So, in my case, I'm using Jenkins as a front end, and Ansible on the back end to perform server configuration and application deployments. Some of these application deployments can take 30 minutes or more, well beyond the 5 minute data retention period of the "queue items".
So the problem that I had to solve, if all I have is a "queue item" ID, then how do I find a "build job" ID, regardless of when I'm checking, seconds later or hours later?
Here was my solution (Note that I required XML output, FYI).
I ran this command:
curl -X POST "http://jenkins_srv:8080/job/MY_JOB/buildwithParameters?this=1&that=2" --user name:pass
This command would return this information:
Runtime responseHeaders Date: Day, ## Non Year xx:yy:zz GMT
X-Content-Type-Options: nosniff
Location: http://jenkins_srv:port/queue/item/123/
Content-Length: 0
Server: Jetty(9.4.z-SNAPSHOT)
From here, I can parse out 123 from the Location field.
I then slept for 10 seconds. After the sleep, I run this command on a 10 second loop:
curl -X GET http://jenkins_srv:8080/queue/item/123/api/xml
I did that until I either:
I got a queue item return that included the xpath //executable/number that's shown in Kdawg's example, or
I got HTML 404 status code for more than 10 minutes, meaning the job hasn't been queue'd yet or I passed the 5 minute data retention window.
The loop in this way handles a burdened Jenkins server that's sluggish on handling queue requests. So presumably if I get to the end of 10 minutes, then my approach will still handle the use case that my automation approach has successfully queue'd and run the job, but it's checking Jenkins outside the data retention window. In this case, I would run this command:
curl -X GET http://jenkins_srv:port/job/MY_JOB/api/xml?tree=builds[id,number,result,queueId]&xpath=//build[queueId=123]
This returns the XML info for any "build job" that also contains a queueId of 123, as shown below:
<?xml version="1.0"?>
<build _class="hudson.model.FreeStyleBuild">
<id>456</id>
<number>456</number>
<queueId>123</queueId>
<result>SUCCESS</result>
</build>
In this way, I was able to authoritatively get a "build job" ID while only having a "queue item" ID regardless of the time difference between when I started and when I checked back.
Assuming that you have a location of http://jenkins_srv:8080/queue/item/123/, you can GET http://jenkins_srv:8080/queue/item/123/api/json?pretty=true to return information about that queue item (you can also not include ?pretty=true if you don't care about formatting, or use api/xml if you want the results in XML).
I don't know if there's standard documentation on the queue API, but it appears that if the queue item has completed (maybe also if it's currently being built?) it will have an executable node. One for my server looked like this:
"executable" : {
"_class" : "org.jenkinsci.plugins.workflow.job.WorkflowRun",
"number" : 10,
"url" : "http://192.168.99.100:32769/job/configure/10/"
}
You can then GET the API for the URL specified in executable.url. In my case, GET http://192.168.99.100:32769/job/configure/10/api/json?pretty=true. From there, you should have all the information you need, including whether or not the build is currently being built, how long the build took/has taken, the result, etc.
Also, if you want information on your entire build queue, you can GET http://jenkins_srv:8080/queue/api/json?pretty=true
Astonishing that Jenkins doesn't track a request to its conclusion with a unique ID.
One element that persists between the queued item and the build item is the list of parameters. If you have the ability/authority to change the config of the jobs, then add an optional parameter REQUEST_ID that the client plucks from the air (e.g. a UUID) and passes in over REST. Then you can quiz the queue and look for the one with your REQUEST_ID, and you can quiz the list of builds and look for the one with your REQUEST_ID.
There's an interesting thing about this that if you want to queue multiple builds in the loop, you might end up getting SAME QUEUE_ID, This happens especially when you have the same parameter and queued builds have not started up. Basically, Jenkins assumes that you are just trying to build this and instead of multiple builds it just assumes that it needs to spin up only a single build, hence the SAME QUEUE_ID, To overcome this, if you add an extra parameter while building the job like UQ_ID=CURRENT_TIMESTAMP (This param doesn't need to be in build) then you will get the unique build number
If there's no param at all in the build you should define at least one param, Because parameterless build won't allow ANY parameter to be passed in the api
you can fetch job details by id
http://localhost:8080/job/{jobName}/{jobId}/api/json
curl --location --request GET 'http://localhost:8080/job/testPipeline/2/api/json' \
--header 'Authorization: Basic 1234' \
Based on the API reference, the continuous parameter will keep the connection open. However, the following curl command returns after about 20 seconds, which seems not true according to the API reference. Could anyone explain this? Thanks.
curl https://cloudant-URL-bluemix.cloudant.com/mydb/_changes?feed=continuous --http1.1
Returns:
"last_seq":"11-g1AAAAYeeJy11M1NwzAUB3DTIiFOdAM4wLElbpzYPtENYAPw84dKlaYItWfYADaADWAD2AA2gA3KBsWuEampSpIiLo4UWb9_3nt2MoRQq99U6ECBHF3qngIcdWDYlrKtRNaO4o7MRhMl8nEn1-PMbm8IBDuz2WzQb4qNoX2xRSQXkkZVERe3_70zLUmDll1h9ysQzQM5JEaBDdye5Eqb81yrEE3K0D2HHgYoIZIow1ej3TI0cuhRiBolKFtCa3Qbek49DlXNmDB69afSMvTEoacBGiexTDX9Q1PPHDoKUYkBuuSX-nGZeuHUq-DAqTQ2WsRVnZodzzftiq7tw4beuNTGPFXTLgCV_3PMfeitD70rQqXAnLGkIlVvYD7z3mc-FEMTmCjtCl33Jnj40cNPDm76YjTXkUgrUmuN7dmHvhTVUA1M8KUjWHc0rx5-W7iF1EQGx-tfGA-_e3hazJwTLhmBitSPNlWbzYcPXfyncqmxYovVDD4Bc-fgbg","pending":0}
Try:
curl 'https://cloudant-URL-bluemix.cloudant.com/mydb/_changes?feed=continuous&heatbeat=1000'
It's probably timing out if there are no changes to report on. See
http://docs.couchdb.org/en/2.0.0/api/database/changes.html