We are using jhipster console to visualize our application logs. I just changed the logstash config to send logs to different indexes based on environment Dev, sit etc. Now the dashboards are broken as they are using the default index logstash-. Is there a way to pass in the index names as command line arguments when starting up docker containers to replace logstash-. Also what is the best way of visualizing multiple indexes in dashboards?
The index pattern is hard-coded in dashboard definitions, just edit their definitions and import them which basically means: clone the jhipster-console git repository, customize it by duplicating dashboards per index and build your own docker image.
Related
I am migrating from Jenkins CI to gitlab CI. In jenkins I was able to parse some extra output files - for example a my_results.xml file which has some lines in XML which we could parse into a custom visualisation like the ones below:
Note: these are just example visualisations.
My XML might have some simple lines like:
<summary>
<warnings>10</warnings>
<errors>2</errors>
</summary>
This would be displayed over time into a graph like in the images above. Is it possible to write a custom parser / visualiser in gitalb CI?
There is no such thing in GitLab as Jenkins plugins.
But you could - for instance - develop a side application that interacts with GitLab through its APIs.
There, you'll be able to do whatever you want. For instance download Job artifacts, store them in a timeseries database, display them in a dashboard.
If the application is a pure web client, it could even be hosted in GitLab pages.
Azure DevOps XDT Transform tasks allow you to build release profiles that transform the base config file with settings that are specific to each environment, such as a connection string that points to different db servers for different environments. The app.dev.config file has transformations for the dev environment, app.qa.config for qa, etc, which are applied during the deployment to the base app.config file.
I need to take this one step further and deploy custom config files for each individual server in a load balanced environment. For example, the DEV environment has two servers dev1.mysite.com and dev2.mysite.com that are load balanced by dev.mysite.com. Each of the two servers needs specific settings in the config file deployed to that server.
I don't (yet) see a way in Azure DevOps to do this. Part of the solution might be to set up variables with the setting that needs to be applied to each environment/server but I haven't figured out how to apply the correct variable to each config.
You can use task Magic Chunks to apply the variable to each config.
You can search for Magic Chunks task in your pipeline and install it to your organization. Then add Config transform task before the deployment task to update the config file with specific setting. For below example settings of magic chunk task:
As above screenshot shows, You can reference your pipeline variables in the tasks.
There are other extension tasks like RegEx Find & Replace you can use to replace the variables in the config files.
As the standard pipeline badge from GitLab looks like this
you can tell pretty well that those are not really distinguishable.
Is there a way to change the pipeline text manually or programmatically to something else for each badge?
Btw, the badges were added with those links
https://gitlab.com/my-group/my-repository/badges/master/pipeline.svg
https://gitlab.com/my-group/my-repository/badges/dev/pipeline.svg
Additional facts:
The pipeline runs locally on my computer
My repo is private
I know it is a bit of an old post, but I was looking for the same and found that it is available now since GitLab 13.1.
The text for a badge can be customized to differentiate between multiple coverage jobs that run in the same pipeline. Customize the badge text and width by adding the key_text=custom_text and key_width=custom_key_width parameters to the URL:
https://gitlab.com/gitlab-org/gitlab/badges/main/coverage.svg?job=karma&key_text=Frontend+Coverage&key_width=130
The example is for the Coverage badge but this also works for Pipelines, so in your case:
https://gitlab.com/my-group/my-repository/badges/master/pipeline.svg?key_text=master&key_width=50
https://gitlab.com/my-group/my-repository/badges/dev/pipeline.svg?key_text=dev&key_width=50
(Found this via https://microfluidics.utoronto.ca/gitlab/help/ci/pipelines/settings.md#custom-badge-text)
There are multiple ways how you can achieve custom pipeline badges in GitLab.
One way could be to use Shields.io which provide a way to generate dynamic badges for your Gitlab repository via a jsonfile.But if your repository is private (only accessible from internal network) then you will get an inaccessible message in your badges.
Otherwise, if your build uses python Docker images or any other python installation with dependencies, you can simply install the anybadge package and generate svg badges to be used in the project from the artifacts directly.
It would be good in future that GitLab offers us more cleaner way to customize the badges, but for now I think those are the workaround solutions.
I have a build up on Azure Pipelines, and one of the steps provides a code metric that I would like to have be consumable after the build is done. Ideally, this would be in the form of a badge like this (where we have text on the left and the metric in the form of a number on the right). I'd like to put such a badge on the README of the repository to make this metric visible on a per-build basis.
Azure DevOps does have a REST API that one can use to access built-in aspects of a given build. But as far as I can tell there's no way to expose a custom statistic or value that is generated or provided during a build.
(The equivalent in TeamCity would be outputting ##teamcity[buildStatisticValue key='My Custom Metric' value='123'] via Console.WriteLine() from a simple C# program, that TeamCity can then consume and use/make available.)
Anyone have experience with this?
One option is you could use a combination of adding a build tag using a command:
##vso[build.addbuildtag]"My Custom Metric.123"
Then use the Tags - Get Build Tags API.
GET https://dev.azure.com/{organization}/{project}/_apis/build/builds/{buildId}/tags?api-version=5.0
Okay, I have a couple inquiries:
1 - Let's say I have a solution that references several external projects. I want to reference specific Labels (that represent stable versions) on those external projects. I know that you can do this by doing a Get Specific Version by Label on those projects. But once you've done that, is there a convenient way to do a Get on the whole solution, and have it preserve all of the specific versions?
Ultimately, I would like to do a single Get and have it get latest where that is applicable and get specific versions where that is applicable. It seems frustrating to have to do separate Gets on all the projects.
2 - Is it possible to build binaries from labels? When an external project is a stable version that isn't going to change, it makes sense to just reference the binary. When you create a label and build it, does it generate binaries in a specific location for that label that can be referenced?
On your first question: While TFS allows you to grab sources by Label, there is no way to setup a a workspace configuration that is bound to a specific Label or Changeset for a specific path. The only thing I can think of would be to create a batch file which fetches the latest version:
tf get $/Project/Sources /Version:T /recusive
tf get $/Project/ComponentA /version:LMyLabelName1 /recursive
tf get $/Project/ComponentB /version:LMyLabelName2 /recursive
The way forward to do this is to publish your external references to a NuGet repository (can be your own) and then configure NuGet to get a specific version. A CI build can publish a new version to your NuGet server. And you can setup your own server so that you don't need to publish all your binaries to a public server.
On your second question: yes you can build by label in the Queue Build screen you can setup the version to build which will be built:
You can specify a Changeset number (C######), Label (LLabelname) etc. Any version spec will do (see the commandline docs for a explanation on version specs).
By default, no easy referencable name is generated if you build by label. I suspect that some clever build customization will allow you to drop the build output in a predefined folder based on the label name, but there is no such out-of-the-box functionality.