Can I use current timestamp ( or day, or else uniq param ) as release in spec rpm file ?
For example, something like this:
Release: 100%{?dist}.test.%{timestamp}
What you can do is define a variable before your preamble, then use it on the Release line. The following example will set the release number to (assuming September 12, 2013) 20130912.
%define build_timestamp %(date +"%Y%m%d")
...
Release: %{build_timestamp}
Related
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("."))
I am using Airflow2.0 with KubernetesPodOperator want to run a command that use as a parameter a file from inside the image ran by the Operator. This is what I used:
KubernetesPodOperator(
namespace=commons.kubernetes_namespace,
labels=commons.labels,
image=f"myregistry.io/myimage:{config['IMAGE_TAG']}",
arguments=[
"python",
"run_module.py ",
"-i",
f'args/{config["INPUT_DIR"]}/{task_id}.json'
],
name=dag_name + task_id,
task_id=task_id,
secrets=[secret_volume]
)
But this gives me the error:
raise TemplateNotFound(template)
jinja2.exceptions.TemplateNotFound: args/airflow2test/processing-pipeline.json
The image does not use any macros.
Anyone has any clue? What do I do wrong?
This was a bug that started with PR released in version 2.0.0 of apache-airflow-providers-cncf-kubernetes.
The goal of the change was to allow templating of .json files. There was a GitHub issue about the problems it created. The bug was eventually resolved by PR which was released in version 2.0.2 of the provider.
Solution:
Upgrade to the latest apache-airflow-providers-cncf-kubernetes (currently 2.0.2)
If upgrade is not an option use custom KubernetesPodOperator
There are two ways to workaround that problem one is to change template_fields the other is to change template_ext:
1st option: As posted on issue by raphaelauv is not to allow rendering of arguments field:
class MyKubernetesPodOperator(KubernetesPodOperator):
template_fields = tuple(x for x in KubernetesPodOperator.template_fields if x != "arguments")
2st option: if you prefer not to render .json files:
class MyKubernetesPodOperator(KubernetesPodOperator):
template_ext = ('.yaml', '.yml',)
Using https://github.com/mikefarah/yq v4
Given a sample.yaml file like this:
spec:
chart:
name: my-chart
version: 0.0.1
---
spec:
chart:
name: something-else
version: 0.0.2
I want to update the version value but only for the instance of .spec.chart.version where the sibling .spec.chart.name element == my-chart. The result would need to output the entire yaml file so that I can edit the YAML file inline.
If I use a select like
yq e -i 'select(.spec.chart.name == "my-chart") | .spec.chart.version = "1.0.0"' sample.yaml
The second instance of .spec has been removed:
spec:
chart:
name: my-chart
version: 1.0.0
Any advice?
yq '(.spec.chart | select(.name == "my-chart") | .version) = "1.0"' file.yaml
Explanation:
First we want to find all the (potential) nodes we want to update, in this case, it's .spec.chart.
Next we filter out those node to be only the ones we're interested in, select(.name == "my-chart")
Now we select the field we want to update .version
Importantly, the whole LHS is in brackets, so those matching version nodes are passed to the update (=) function. If you don't do this, then the filter happens before (and separately to) the update - and so you only see filtered results.
Disclaimer: I wrote yq
I have a downloaded file through helm inspect called sftp.yaml
I have a parameter in that sftp.yaml file:-
sftp:
allowedMACs: "hmac-sha2-512"
allowedCiphers: aes256-ctr
Now if i install the corresponding helm chart after commenting out the entire line of "allowedMACs" from custom values files i.e. "sftp.yaml", then K8s takes the delta of sftp.yaml and the actual values.yaml and then use values.yaml's "allowedMACs".
However What i want is if "allowedMACs" line is commented in "sftp.yaml" custom values file, then it should not set the env variable at all, or sets it as null.
presently my deployment file's env section looks like
- name: MACs
value: {{ default "" .Values.sftp.allowedMACs | quote }}
You need to either override (with new value) or unset the value, if you only comment out the section you are not doing any of the above and the default value is going to be used.
Basically you are looking to unset a default value. As per banzaicloud example this can be done like so:
helm install stable/chart-name --set sftp.allowedMACs=null
You can also use override value file in a similar way:
sftp:
allowedMACs: null
allowedCiphers: aes256-ctr
This is available in Helm since version 2.6. If you like in-depth information you can review the issue and the subsequent PR that introduced the feature.
yeah I think helm would retrieve values from all values files, so if allowedMACs is in one of those it'll get populated. If this parameter is affected only by sftp.yaml file should it really belong only to it and would i make sense to remove it from main values.yaml?
I have several servers running under centos 6.3 and I faced issue that perl module DateTime treats Europe/Moscow timezone as UTC+3
[ulan#rt-virtual ~]$ perl -MDateTime -e 'print DateTime->now()->set_time_zone("Europe/Moscow"), "\n";'
2013-12-19T11:11:38
but in fact it is UTC+4 and system tools like zdump or date work correctly
[ulan#rt-virtual ~]$ zdump Europe/Moscow
Europe/Moscow Thu Dec 19 12:11:47 2013 MSK
I updated tzdata and DateTime module but it didn't help.
How can I amend this?
Thanks.
Well, DateTime module is doing its magic by following the rules specified in the TimeZone modules specific for each timezone. For Europe/Moscow, the module's is DateTime::TimeZone::Europe::Moscow. The problem is all the files are generated automatically corresponding to the rules existing when a specific version of DateTime module is released.
In this case one very important change - Russia's stopping following DST routines in 2011 - wasn't obviously reflected in that file. So updating - either the whole module or only the relevant TimeZone part - should have fixed the issue.
You can use your systems tzfile(5), using DateTime::TimeZone::Tzfile. Not only does it perform better than DateTime::TimeZone it also removes the need to have redundant data that needs to be in sync.
$tz = DateTime::TimeZone::Tzfile->new('/etc/localtime');
$dt = DateTime->now(time_zone => $tz);