feat: add Artifacthub annotation 'artifacthub.io/changes' #881
justusbunsi Assignees 
42wim 
6543 
a1012112796 
Akkuman 
appleboy 
axifive 
betacat0 
blumia 
bwko 
caicandong 
ChristopherHX 
DaanSelen 
davidsvantesson 
delvh 
denyskon 
fuxiaohei 
gary-kim 
garymoon 
giteabot 
guillep2k 
HesterG 
hiifong 
jaqra 
jolheiser 
jonasfranz 
jpraet 
kdumontnu 
kemzeb 
kerwin612 
khmarbaise 
KN4CK3R 
kolaente 
lafriks 
lng2020 
lotherk 
luhahn 
lunny 
mrsdizzie 
noerw 
pat-s 
puni9869 
renovate-bot 
richmahn 
rossigee 
sapk 
screenshots 
sillyguodong 
silverwind 
smartclip_tim 
strk 
tboerger 
techknowlogick 
TheFox0x7 
tobiasbp 
typeless 
volker.raschek 
wolfogre 
wxiaoguang 
yardenshoham 
yp05327 
zeripath 
Zettat123
Clear assignees
42wim 6543 a1012112796 Akkuman appleboy axifive betacat0 blumia bwko caicandong ChristopherHX DaanSelen davidsvantesson delvh denyskon fuxiaohei gary-kim garymoon giteabot guillep2k HesterG hiifong jaqra jolheiser jonasfranz jpraet kdumontnu kemzeb kerwin612 khmarbaise KN4CK3R kolaente lafriks lng2020 lotherk luhahn lunny mrsdizzie noerw pat-s puni9869 renovate-bot richmahn rossigee sapk screenshots sillyguodong silverwind smartclip_tim strk tboerger techknowlogick TheFox0x7 tobiasbp typeless volker.raschek wolfogre wxiaoguang yardenshoham yp05327 zeripath Zettat123 No Assignees
Notifications
Due Date No due date set.
Dependencies
No dependencies set.
Reference: gitea/helm-gitea#881
Reference in New Issue
Block a user
No description provided.
Delete Branch "volker.raschek/helm-chart:feat/support-artifacthub-annotation-changes"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The following PR add the annotation 'artifacthub.io/changes'. For each semantic
commit will be the annotation extended. Further information can be found in the
documentation of
Artifacthub.io.
The CI has been adapted. The binary jq as well as yq in >= v4.0 is required.
Otherwise will not be concatenated the YAML file correctly via the yq expression,
because the
loadstr()expression is not available in lower versions.Additionally the relation between the semantic commit and the Artifacthub.io
change log type should be clarified. The current relationshiop can be adapted if
needed.
Furthermore, yq will be installed as part of the CI steps. It would be great if
yq is also available as deb package in >=v4.0. This would reduce the boiler
plate to install yq and maintain the version via renovate.
Regarding the renovate expression. In my environment works this expression, but
I don't know if it also works in this gitea/renovate instance.
Hi @justusbunsi, @ChristopherHX and @pat-s,
please take a review and inform me about required changes. I let the PR on WIP until I have verified the release workflow on my own instance.
Volker
Thanks! I am using artifacthub.io myself. What I don't like about the automatic parsing is that everything must go into
Chart.yaml. This really creates a mess, especially with all those PR entries.If we do this, the changelog entries should IMO be added at the end of the file, not at the top. As a user I expect to see the Chart info first, then everything else.
WRT to the script:
Workflow: You can also add a new one using an Alpine container and install
yqin there.2ecde05582to540350dbfaGood morning,
you're absolutely right, but the changes in the
Chart.yamlwas my fault. The intention is, that.annotations."artifacthub.io/changes"will be generated and added only durning the release. The version will be set via helm and the chart will than be packaged. The annotation including the changelog is than part of the helm chart tarball, but not part of theChart.yamlof the repository.For this reason, the user will never see the annotations in
Chart.yaml. I probably failed to commit the change inChart.yamlduring the test run.I think the question has become superfluous after I explained the workflow :-)
I will look at
library/alpineto install and useyqin it.540350dbfato81a0dc54e981a0dc54e9to16d82e3c9cHi @pat-s,
i've tested the CI pipeline on my own instance. Some workflows as well as some steps of the release workflow has been disabled, because I don't have the secrets. Nevertheless, the annotations has been added as expected. I've let the CI print the
Chart.yamlfile on stdout: https://git.cryptic.systems/volker.raschek/helm-gitea/actions/runs/55#jobstep-9-1Please review my PR now 😄
Further feedback is welcome. FYI @justusbunsi
WIP: feat: add Artifacthub annotation 'artifacthub.io/changes'to feat: add Artifacthub annotation 'artifacthub.io/changes'16d82e3c9cto162a3c7e8d162a3c7e8dto8bf44b06a6Thanks!
Somewhat sad that artifacthub didn't implement conv commits and instead now there is a new logic needed parsing conv commit tags into their labeling structure.
Overall LGTM, you wanna check if my suggestion helps.
@@ -23,3 +18,1 @@tar -xzf helm-v${{ env.HELM_VERSION }}-linux-amd64.tar.gzmv linux-amd64/helm /usr/local/bin/rm -rf linux-amd64 helm-v${{ env.HELM_VERSION }}-linux-amd64.tar.gz# determine operating systemWhat about
dpkg --print-architecture?Good question, I can definitely change that. I mean, we won't be switching away from ubuntu that quickly.
8bf44b06a6to8f42541b3e8f42541b3eto4eed5ca3dfWhen using
dpkg --print-architecturelet's use it in a way to save lines :)PS: Please try to avoid force pushes in PRs, unless really necessary.
@@ -18,0 +13,4 @@with:fetch-depth: 0- name: Determine Architecture and Operating System to support x86_64 and ARM based CI nodesThis whole block can be omitted by using
dpkg --print-architecture. You can create the content of an env var dynamically with it.the following option is required for
add-annoations.sh:Regarding the block
Determine Architecture and Operating System to support x86_64 and ARM based CI nodes: Yes, it's true that we can define the content of an env var dynamically like example below:This would lead to an issue, that
echo "INFO: Set environment variable ARCH=${ARCH}"will never print the stored value ofARCH, because theGITHUB_ENVis not than evaluated. I would prefer for debugging to log the value ofARCHandOS, but when you would prefer to reduce the CI commands I can remove the echo command as well to avoid the mentioned issue.Didn't comment on that :)
What is the benefit of a dedicated step setting and printing the architecture?
archanddpkg --print-architectureare standard practice, they don't need debugging or high verbosity. Their return is clear :)@volker.raschek The next release is currently blocked by this (in case you wanna get it in and not wait for the next one). LMK if you wanna finish here in the next days or if we should continue with the release.
This may sound rather stupid and is due to my current work, but there are actually programs that return a different value at runtime. I don't want to accuse
dpkgof this at all, but I have had experiences with other programs in the context of CI that have almost driven me to despair.I have therefore got into the habit of relying as little as possible on the independent approach of programs in the CI. Especially when I am dependent on preparing an environment properly.
Since this seems superfluous for the project in the first place, I agree with you. I have therefore provided another commit that replaces OS and ARCH with a static value
linuxas well asdpkgcommands, even if I can't endorse the latter.The following patch replaces ${OS} and ${ARCH} with a static value `linux` and the command `dpkg --print-architecture`.da0eda0ffcto2b1979b43cI've rebased the PR, because the helm version has been updated and leads to a merge conflict.
Still a merge + normal push would have sufficed 😃️
Just for my own curiosity: why did you go with a force-push to solve the conflict?
(I am seeing force-pushes more often lately and still trying to understand where the pattern comes from and why users are doing it so often.).
LGTM!
giteabot referenced this pull request2025-06-16 14:22:07 +00:00 In this specific example, the CI ran through, but with the note that there is a conflict with the latest changes in
origin/main.Again, I can only speak from my experience with git. As a rule, you want to ensure that there is only one fork for a feature that is being developed in a branch. If you merge these, you merge the branch instead of doing a rebase. This enables you to revert a complete feature back based on the merge commit.
However, if a merge has been made from
origin/mainto the feature branch in the meantime, a history similar to a "fan" is created. People often try to avoid this because it contains unnecessary merge commits and bloats the git object store, especially for large mono projects.