I have a YAML file with semantic versioning number like this:
version: 1.0.1
I need to increment PATCH part of the version. Is it possible to do it with yq?
UPDATE:
The question is about mikefarah/yq implementation which is installed with brew install yq.
Please clarify which implementation of yq you are using. Apart from that, the general approach would be to split the string at the dots, convert the last item to a number and increment it, and then rejoin the array with dots.
Here's one way of doing it using the kislyuk/yq implementation:
.version |= (./"." | last |= tonumber + 1 | join("."))
And here's the same using the mikefarah/yq implementation:
.version |= (split(".") | .[-1] |= ((. tag = "!!int") + 1) | join("."))
Related
I have the following map of strings and I would like to change the value of "image.tag" key .
I tried the following but it does not work as I expected. The problem here is that image.tag is a string but I am not sure how to express that. Thanks
yq eval --inplace ".spec.chart.values.\"image.tag\": \"$TAG\"" values.yaml
spec:
chart:
values:
image.tag: master
You don't have to use double quotes for reading variables from shell. mikefarah/yq provides a method strenv to load variables (also environment) form the shell.
Also by using single quotes, you can just wrap image.tag under double quotes to let it be treated as a single word.
Use the style method to set quotes for the updated value style="double" reflects the updated tag value to be treated as a string.
newtag="foo" yq e --inplace '.spec.chart.values."image.tag" |= strenv(newtag) | ..style="double"' values.yaml
or if the new tag is defined as a shell variable say TAG
newtag="$TAG" yq e --inplace '.spec.chart.values."image.tag" |= strenv(newtag) | ..style="double"' values.yaml
Note that, if you are using yq version above 4.18.1, the eval action e is the default one and can be skipped altogether.
I am trying to automate the release of software using semantic-release. Everything is working fine. I run this command npx semantic-release --no-ci --dry-run and get the following output in the terminal
...some other output
[1:01:55 pm] [semantic-release] › ⚠ Skip v0.1.1 tag creation in dry-run mode
[1:01:55 pm] [semantic-release] › ✔ Published release 0.1.1 on default channel
[1:01:55 pm] [semantic-release] › ℹ Release note for version 0.1.1:
## 0.1.1 (2021-01-24)
### Bug Fixes
* ravgeet is fixing things (92797f6)
* removed unwanted files (bdcc9ff)
* this is another fix (dbef2fd)
Now I need to get the release notes from the output
## 0.1.1 (2021-01-24)
### Bug Fixes
* ravgeet is fixing things (92797f6)
* removed unwanted files (bdcc9ff)
* this is another fix (dbef2fd)
How can I do so using grep command or any other means?
With GNU sed.
| sed -n '/^##/,$p'
-n: Do not output anything unless it is explicitly stated (here with command p)
x,yp: You can replace x and y with a regex (here: /^##/), a line number or a special character like $. $ matches here last line in input.
/^##/: regex for lines starting with two #
p output sed's pattern space (current line).
| sed '/^##/,$!d'is a more compact notation. I translate !d with don't delete.
See: man sed and The Stack Overflow Regular Expressions FAQ
I'm trying to use yq https://github.com/mikefarah/yq v4.3.2 to add a yaml value in a CloudFormation template like so:
Mappings:
RegionMap:
us-east-1:
AMI: 'ami-YeahRight'
Instead, what I'm getting is:
Mappings:
RegionMap:
us-east-1:
AMI: ami-YeahRight
The style bits in the documentation and from this SO answer yq processing a string with quotation marks made me think that this portion of a bash script would work however the style portion is ignored.
region="us-east-1"
ami="ami-YeahRight"
echo Inserting $ami into $region
yq eval '.Mappings.RegionMap.'"$region"'.AMI='"$ami"' style="single"' -i temp.yaml
I've tried a whole bunch of similar bits but can't seem to crack this nut. Any help here would be greatly appreciated!
mikefaraq/yq is going through major leap of changes starting from v4 and I'm not surprised that things are breaking in-between.
On v4.4 I can make this work, but using env() function to look-up the variables and use the ..style attribute to set the quoting style
region="us-east-1" ami="ami-YeahRight" yq e '.Mappings.RegionMap.[env(region)] = env(ami) | ..style="single"' yaml
I have a yaml file that looks something like this:
a:
desc:
value: 1
b:
desc:
value: 2
# ...
I want to convert it to this:
a: 1
b: 2
# ...
In yq v2, I used the command .[] |= .value' to update each element of the array to the value in the .value field. Is there a way to do this with yq v3?
cat config.yaml | yq w - "*" "*.value"
yields
a: *.value
b: *.value
# ...
``
Your claim seems to be contradicting each other. There are two versions of yq implementations out there. A python implementation as a wrapper over jq and other written in Go.. See my answer that covers in details about those versions.
When you said you used .[] |= .value in yq v2, that's actually not the Go version, but the version with the Python wrapper over jq, since that syntax matches its DSL. But the other attempt yq w - "*" "*.value" seems to be the actual Go version.
Since there is an uncertainty around which version of yq in installed for you, I'll try to provide my view in both the versions
kislyuk's yq
yq -y '.[] |= .value' yaml
mikefarah's yq
The Go version does not have dynamic transformational capabilities like its Python version and does not support this type of update directly. Because the write/new field creations syntax is simply
yq w <yaml_file> <path_expression> <new value>
where the new value is not an expression but a literal value. Had it supported expressions, we could have conjured up a way to do the transformation. The Go version is otherwise good, but lacking support in some key transformational capabilities.
P.S. I've raised a GitHub feature request to allow such transformations. See https://github.com/mikefarah/yq/issues/602
As of today Dec 21st, 2020, yq v4 is in beta and supports this transformation. Download the v4 version and try
yq eval '.[] |= .value' test.yml
I'm trying to understand how the Postgres 9.1 rpms are built on CentOS/RHEL 6, so I'm taking a look at the spec file from the source rpms.
What does the following syntax do/mean? Specifically, the question mark and exclamation point?
%{!?test:%define test 1}
%{!?plpython:%define plpython 1}
%{!?pltcl:%define pltcl 1}
%{!?plperl:%define plperl 1}
%{!?ssl:%define ssl 1}
%{!?intdatetimes:%define intdatetimes 1}
%{!?kerberos:%define kerberos 1}
%{!?nls:%define nls 1}
%{!?xml:%define xml 1}
%{!?pam:%define pam 1}
%{!?disablepgfts:%define disablepgfts 0}
%{!?runselftest:%define runselftest 0}
%{!?uuid:%define uuid 1}
%{!?ldap:%define ldap 1
I understand you can define a macro variable with %define <name>[(opts)] <value>, and I believe the exclamation mark is a logical negation operator. I can't find any info on the question mark or examples like the above though. Seems like some sort of test before defining the macro variable.
Here is a paste of the spec file.
Lets review a single item here:
%{!?plpython:%define plpython 1}
On line 102 we also see this:
%if %plpython
BuildRequires: python-devel
%endif
As you said, we know that this is a macro, that can also be confirmed via the Fedora docs. Now if we expand on our search into the Fedora documentation we find conditional macros. This states the following:
You can use a special syntax to test for the existence of macros. For example:
%{?macro_to_test: expression}
This syntax tells RPM to expand the expression if macro_to_test exists, otherwise ignore. A leading exclamation point, !, tests for the non-existence of a macro:
%{!?macro_to_test: expression}
In this example, if the macro_to_test macro does not exist, then expand the expression.
The Fedora docs have provided the answer, if the plpython macro doesn't exist, then
%define plython 1
If you look at line 38 you can also see this:
# In this file you can find the default build package list macros. These can be overridden by defining
# on the rpm command line:
# rpm --define 'packagename 1' .... to force the package to build.
# rpm --define 'packagename 0' .... to force the package NOT to build.
# The base package, the lib package, the devel package, and the server package always get built.
So if you don't define the the macro when you build the package (I imagine this is what most users would do) it's going to ensure that the buildrequires are properly configured for what appears to be a standard PostgreSQL installation.