How to send notes.txt output to a file instead of dumping it to the console? - kubernetes-helm

I want Helm to write the output of notes.txt to a local file instead of just dumping it to the console. I want to write a JSON file that is going to be read by another system (that is going to send a Slack message).
If that is not possible is there a separate Helm command that just outputs notes.txt without having to do a full deploy?
I don't want to have to try to capture and parse it out of the entire deployment output.

helm status <release> will show you the state of a release. This also contains the notes.txt output.
Helm offers the ability to specify the output format of the helm status <release-name> command (doc). So by running:
$> helm status <release> -o json
you will get detailed information about the deployed release in json format:
{
"name": "release",
"info": {
"first_deployed": "..",
"last_deployed": "..",
"deleted": "",
"description": "Install complete",
"status": "deployed",
"notes": "THIS IS THE FIELD YOU WANT"
},
"manifest": "...",
"version": 1,
"namespace": "..."
}
Depending on the shell you're using, you can then directly save the output in a file ( below for bash ):
$> helm status <release> -o json > out.json
Or use other mechanism to further process the json file before saving ( like jq):
$> helm status <release> -o json | jq -r '.info.notes'
...
[ only the notes part of the release ]
...

Related

GitHub Actions: How to access to the log of current build via Terminal

I'm trying to get familiar with Github Actions. I have configured my workflow in a way, that every time I push my code to GitHub, the code will automatically be built and pushed to heroku.
How can I access the build log information in terminal without going to github.com?
With the latest cli/cli tool named gh (1.9.0+), you can simply do
(from your terminal, without going to github.com):
gh run view <jobId> --log
# or
gh run view <jobId> --log-failed
See "Work with GitHub Actions in your terminal with GitHub CLI"
With the new gh run list, you receive an overview of all types of workflow runs whether they were triggered via a push, pull request, webhook, or manual event.
To drill down into the details of a single run, you can use gh run view, optionally going into as much detail as the individual steps of a job.
For more mysterious failures, you can combine a tool like grep with gh run view --log to search across a run’s entire log output.
If --log is too much information, gh run --log-failed will output only the log lines for individual steps that failed.
This is great for getting right to the logs for a failed step instead of having to run grep yourself.
And with GitHub CLI 2.4.0 (Dec. 2021), gh run list comes with a --json flag for JSON export.
Use
curl \
-H "Accept: application/vnd.github.v3+json" \
https://api.github.com/repos/<github-user>/<repository>/actions/workflows/<workflow.yaml>/runs
https://docs.github.com/en/free-pro-team#latest/rest/reference/actions#list-workflow-runs
This will return a JSON with the following structure:
{
"total_count": 1,
"workflow_runs": [
{
"id": 30433642,
"node_id": "MDEyOldvcmtmbG93IFJ1bjI2OTI4OQ==",
"head_branch": "master",
"head_sha": "acb5820ced9479c074f688cc328bf03f341a511d",
"run_number": 562,
"event": "push",
"status": "queued",
"conclusion": null,
"workflow_id": 159038,
"url": "https://api.github.com/repos/octo-org/octo-repo/actions/runs/30433642",
"html_url": "https://github.com/octo-org/octo-repo/actions/runs/30433642",
"pull_requests": [],
"created_at": "2020-01-22T19:33:08Z",
"updated_at": "2020-01-22T19:33:08Z",
"jobs_url": "https://api.github.com/repos/octo-org/octo-repo/actions/runs/30433642/jobs",
"logs_url": "https://api.github.com/repos/octo-org/octo-repo/actions/runs/30433642/logs",
"check_suite_url": "https://api.github.com/repos/octo-org/octo-repo/check-suites/414944374",
"artifacts_url": "https://api.github.com/repos/octo-org/octo-repo/actions/runs/30433642/artifacts",
"cancel_url": "https://api.github.com/repos/octo-org/octo-repo/actions/runs/30433642/cancel",
"rerun_url": "https://api.github.com/repos/octo-org/octo-repo/actions/runs/30433642/rerun",
"workflow_url": "https://api.github.com/repos/octo-org/octo-repo/actions/workflows/159038",
"head_commit": {...},
"repository": {...},
"head_repository": {...}
]
}
Access the jobs_url with a PAT that has repository admin rights.

How to make trigger command using watchman?

Hi I will be using watchman to upload images. The images will have folders so I will be using .json to make the command.
These are my images:
/home/user/Documents/Images/folder1/image1.png
/home/user/Documents/Images/folder2/image2.png
I have a list of export environment variables watchman_env
export CONDA_ENV=image_uploader
export IMG_FOLDER=/home/user/Documents/Images
export UPLOADER_SCRIPT=/home/user/Documents/Script/uploader.sh
export PYTHON_UPLOADER=/home/user/Documents/Script/img_uploader.py
export JSON_TRIGGER=/home/user/Documents/Script/uploader.json
This is my uploader script, ~/Script/uploader.sh
. watchman_env
conda run -n $CONDA_ENV python $PYTHON_UPLOADER $IMG_FOLDER
This is my json configuration, ~/Script/uploader.json:
["trigger", "/home/user/Documents/Images", {
"name": "img_uploader",
"expression": ["match", "**/*.png"],
"command": ["/home/user/Documents/Script/uploader.sh"]
}]
I run the command using another bash file, init.sh, since I want to run some few more commands.
. watchman_env
watchman --json-command < $JSON_TRIGGER
When I run uploader.sh my python script uploads the two images. However, when I run init.sh, it does not trigger. What is wrong with my code? And is that correctly how to use json trigger?
wathman version: 4.9.0
I just added to the expression wholename and finally worked.
["trigger", "/home/user/Documents/Images", {
"name": "img_uploader",
"expression": ["match", "**/*.png", "wholename"],
"command": ["/home/user/Documents/Script/uploader.sh"]
}]

dotnet new --install shows usage information

When I try to install a new template using the following:
dotnet new --install . --name MyTemplate
or
dotnet new --install "Path" --name MyTemplate
I get the usage information:
Usage: new [options]
Options:
-h, --help Displays help for this command.
-l, --list Lists templates containing the specified name. If no name is specified, lists all templates.
-n, --name The name for the output being created. If no name is specified, the name of the current directory is used.
-o, --output Location to place the generated output.
-i, --install Installs a source or a template pack.
-u, --uninstall Uninstalls a source or a template pack.
--nuget-source Specifies a NuGet source to use during install.
--type Filters templates based on available types. Predefined values are "project", "item" or "other".
--dry-run Displays a summary of what would happen if the given command line were run if it would result in a template creation.
--force Forces content to be generated even if it would change existing files.
-lang, --language Filters templates based on language and specifies the language of the template to create.
I have a .template.config directory with a template.json file within.
The contents of the template.json file are something like this:
{
"author": "My Department",
"classifications": [
"Solution Template"
],
"name": "My Template Name",
"identity": "My Template Identity",
"shortName": "mytemplate",
"tags": {
"language": "C#"
},
"sourceName": "Company.Product",
"preferNameDirectory": "true"
}
I certainly wish it would tell me what I'm doing wrong. This has worked for me in the past.
The way the dotnet new --install command works is a bit confusing unfortunately. The installation can be successful but the output does not make it obvious. You will get the usage information and a list of installed templates that should include your new one.
As mentioned in the comments, there is a bug filed that aims to tidy this up.
I was seeing similar results running dotnet new -i IdentityServer4.Templates, but the package wasn't being installed and no error or other info was being displayed.
Turns out nuget.org wasn't configured as a package source (new machine I guess? - thought that was configured by default when installing visual studio though).
Here's the nuget.org feed at the time of this writing:
https://api.nuget.org/v3/index.json
And here's info for configuring them in case it helps someone who hasn't done that:
https://learn.microsoft.com/en-us/nuget/consume-packages/install-use-packages-visual-studio#package-sources

How do I deploy specific tag of my docker image in kubernetes

My deployment JSON file have following entry from my image, where 49 is build number. I'm confused how do I use VSTS or kubectl to replace that number with each incremental build. VSTS provides command line options to cubectl command, is it possible to specify something like cubectl -f file.json -imagetag $TAG or something?
"containers": [
{
"name": "jietest",
"image": "myreg.azurecr.io/jietest:49",
"resources": {},
You can use kubectl set image to update container image of a resource.
For example: kubectl set image -f file.json jietest=myreg.azurecr.io/jietest:$TAG.

jhipster kubectl - unable to decode " ": Object 'Kind' is missing

When running this command:
kubectl apply -f tenten
I get this error:
unable to decode "tenten\.angular-cli.json": Object 'Kind' is missing in '{
"project": {
"$schema": "./node_modules/#angular/cli/lib/config/schema.json",
"name": "tenten"
},
"apps": [{
"root": "src/main/webapp/",
"outDir": "target/www/app",
"assets": [
"content",
"favicon.ico"
],
"index": "index.html",
"main": "app/app.main.ts",
"polyfills": "app/polyfills.ts",
"test": "",
"tsconfig": "../../../tsconfig.json",
"prefix": "jhi",
"mobile": false,
"styles": [
"content/scss/vendor.scss",
"content/scss/global.scss"
],
"scripts": []
}],
It looks like you're running this from the parent directory of your applications. You should 1) create a directory that's parallel to your applications and 2) run yo jhipster:kubernetes in it. Then run kubectl apply -f tenten in that directory after you've built and pushed your docker images. For example, here's the output when I run it from the kubernetes directory in my jhipster-microservices-example project.
± yo jhipster:kubernetes
_-----_
| | ╭──────────────────────────────────────────╮
|--(o)--| │ Update available: 2.0.0 (current: 1.8.5) │
`---------´ │ Run npm install -g yo to update. │
( _´U`_ ) ╰──────────────────────────────────────────╯
/___A___\ /
| ~ |
__'.___.'__
´ ` |° ´ Y `
⎈ [BETA] Welcome to the JHipster Kubernetes Generator ⎈
Files will be generated in folder: /Users/mraible/dev/jhipster-microservices-example/kubernetes
WARNING! kubectl 1.2 or later is not installed on your computer.
Make sure you have Kubernetes installed. Read http://kubernetes.io/docs/getting-started-guides/binary_release/
Found .yo-rc.json config file...
? Which *type* of application would you like to deploy? Microservice application
? Enter the root directory where your gateway(s) and microservices are located ../
2 applications found at /Users/mraible/dev/jhipster-microservices-example/
? Which applications do you want to include in your configuration? (Press <space> to select, <a> to toggle all, <i> to i
nverse selection)blog, store
JHipster registry detected as the service discovery and configuration provider used by your apps
? Enter the admin password used to secure the JHipster Registry admin
? What should we use for the Kubernetes namespace? default
? What should we use for the base Docker repository name? mraible
? What command should we use for push Docker image to repository? docker push
Checking Docker images in applications' directories...
ls: no such file or directory: /Users/mraible/dev/jhipster-microservices-example/blog/target/docker/blog-*.war
identical blog/blog-deployment.yml
identical blog/blog-service.yml
identical blog/blog-postgresql.yml
identical blog/blog-elasticsearch.yml
identical store/store-deployment.yml
identical store/store-service.yml
identical store/store-mongodb.yml
conflict registry/jhipster-registry.yml
? Overwrite registry/jhipster-registry.yml? overwrite this and all others
force registry/jhipster-registry.yml
force registry/application-configmap.yml
WARNING! Kubernetes configuration generated with missing images!
To generate Docker image, please run:
./mvnw package -Pprod docker:build in /Users/mraible/dev/jhipster-microservices-example/blog
WARNING! You will need to push your image to a registry. If you have not done so, use the following commands to tag and push the images:
docker image tag blog mraible/blog
docker push mraible/blog
docker image tag store mraible/store
docker push mraible/store
You can deploy all your apps by running:
kubectl apply -f registry
kubectl apply -f blog
kubectl apply -f store
Use these commands to find your application's IP addresses:
kubectl get svc blog
See the end of my blog post Develop and Deploy Microservices with JHipster for more information.