We are running a Jenkins instance with various test jobs as part of the build chain.
I would like to integrate the build, test trend and general CI status information into graphs/widgets using the Shopify Dashing dashboard http://shopify.github.io/dashing/.
In other words, to have a standalone dashboard that indicates key info from the Jenkins instance.
Does anyone have experience with doing this kind of thing? Can you point me in the direction of any good resources/tutorials etc?
Many thanks
Jenkins' url structure is pretty rigid. For example, the build time trend graph for a project would be available at:
http://<jenkinshost>:<port>/job/<jobname>/buildTimeGraph/png
etc. You should be able to just statically link to these using tags in your HTML / ERB / templating language of your choice.
Other information is available via the remote access rest api, for e.g.
http://<jenkinshost>:<port>/job/<jobname>/lastSuccessfulBuild/api/json?pretty=true
would give you a structure containing a lot of project metadata
Have a look at the documentation on the remote access API: https://wiki.jenkins-ci.org/display/JENKINS/Remote+access+API
Related
I'm trying to get my head around if replacing our current CI/CD tool with Github Actions is a pro or con.
My team is currently using GitHub and TeamCity for CI/CD. I find this limiting as it's a separate team that configures the different stages. We use Airflow to schedule our DBT production, so we don't use DBT Cloud.
I'm wondering if there's any benefit to replacing TeamCity with Github Actions as we can write the configuration of the stages (compile, run, test, lint) ourselves. I'm interested in implementing Slim CI , which I don't believe is possible with TeamCity.
Would anyone be able to with the pros and cons of using GitHub Actions alongside Airflow? Is it possible? I'm struggling to find any documentation on using both Actions whilst running DBT production on Airflow.
Right now, my source of information comes from this: https://towardsdatascience.com/how-to-deploy-dbt-to-production-using-github-action-778bf6a1dff6
It mentions "Well, it depends. If you don’t have Airflow running in productions already, you will probably not need it now. There are more simple/elegant solutions than this (dbt Cloud, GitHub Actions, GitLab CI). Also, this approach shares many disadvantages with using a compute instance, such as waste of resources and no easy way for CI/CD."
My main goal is to get rid of TeamCity and implement Slim CI with Github Actions.
Thank you in advance!
I have been working on a project in which i need to track the build time of the application when i make a commit. How can we push the build time data to a server ?
Reliza Hub (disclaimer I'm working on the tool) - provides build time analytics among other things. Just setup project per Getting Started guide here - https://docs.relizahub.com/guide/#description (this one already uses GitHub Actions).
Here is sample GitHub Actions integration script for docker images which includes sending build time data: https://github.com/relizaio/reliza-hub-integrations/blob/master/github-actions/dockerBuild.yml
In theory if you modify the script, you could similar data to your own platform such as ELK.
One note though that build time in this case does not include the time it takes for GitHub Actions to set up build environment.
After setting everything up you would get build time analytics chart in the project analytics which looks as following: https://i.imgur.com/uCn3QKP.png
Alternatively, you can stream build time metadata elsewhere (suck as ELK) using similar principles as in sample integration yaml referenced above.
Recently research different build tools , GCP CloudBuild is one of the selection
https://github.com/GoogleCloudPlatform/cloud-builders
one of require is work loop an array list and write the function only once and run in parallel
however i did not find Cloudbuild mention any about matrix build
Function which provided by Jenkins Plugin https://www.jenkins.io/blog/2019/11/22/welcome-to-the-matrix/
or Github Action https://docs.github.com/en/free-pro-team#latest/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix
Cloud Run is not designed to work with Jenkins out of the box and the links you included do not mention how to do this.
As indicated [1] the best product to integrate Jenkins inside Google Cloud is to use Google Kubernetes Engine (GKE).
[1] https://cloud.google.com/jenkins
We are looking for an option in Artifactory Pro edition, where want to make a central dashboard for downloaded artifacts. Currently the each artifacts has count for # of downloads but we want to extend it more -
Number of downloads
Who downloaded it
from where its downloaded
Dashboard with filter criteria. Please help if anybody has build this type capability. I know probably we can use a plugin for this getting metrics and storing it to somewhere else. But we are looking for option provided by JFrog Artifactory.
Package view is part of the Platform versions (Artifactory 7.x and above): https://www.jfrog.com/confluence/display/JFROG/Package+Management
I suggest you upgrade as this is pretty much what you need.
On your current version there isn't such dashboard, but you can gather the information easily using the Artifactory Query Language: https://www.jfrog.com/confluence/display/JFROG/Artifactory+Query+Languagea
There is no metrics dashboard provided by Jfrog out of the box that would fit this need.
As mentioned by Angello you need to scrape the metrics yourself using the AQL or using different APIs provided by Jfrog then use that data to post onto a dashboard custom made for your usecase.
I wasn't able to find solid information on this and I wanted to ask developers who use Parse Dashboard:
What are the pros/cons of Parse Dashboard local installation vs deployment?
I currently run the Parse Dashboard on local installation, but I know that deployment to Heroku is also an option (my app is deployed on Heroku). I wanted to gather some information before deploying/not deploying.
Thank you!
I also have it running locally and I think for security reasons it's best to do so. If you setup the dashboard on the same server on which Parse is running, then you will have to take security measure to protect access to the dashboard and the config file which includes your masterkey and all that. This definitely outweighs the arguments to host it locally, which in my opinion only is that it's easier to access the dashboard.
If you really want to setup a dashboard on a server at least do it on a separate server.