I speak here {^_^}

Notes: cleaning PR for custom alertmanager template changes in intly-operator, demonstrating dynamic-client, fixing broken CNCF CLA label #2

May 1, 2021

Did the following today:

  • In the morning, I rebased this PR (Add custom alertmanager go template to enhance email config) with integreatly-operator master branch. And it created a terrible mess (some really serious mess, with changes in 551 files), took me an hour to clean it & finally make it even with the master branch. Hoping it’ll be merged next week, so we get it atleast in the RHOAM 1.7 release.

  • And rest of the day was entirely playing around k8s python dynamic clinet. I learnt a lot of stuff around how to create, list, patch (update) & delete k8s resources (CustomResourceDefinition (CRD)s, Custom Resources (CR), Services, Configmaps, Replication-Controller, & nodes). And as a result of all the learning, I raised quite a long PR today (the bot marked it Size/XL& that means the review will take time). Anyways, the fun part was something that happened when I was done with all my changes & I raised the PR. The kubernetes upstream project accepts changes from folks who sign the Contributor License Agreement (CLA). And well, it is sure that I’ve signed it because that is why I got 3 of my PRs merged last week itself. But as I raised the PR today, the bot labelled it cncf-cla: no which means even if everything gets approved, the PR won’t be merged. I cross-checked once again if I needed to sign it again or something, but no, everything was fine with the CLA. Then I was digging within my previous commit information & after a roughly 30/45 min brainstorming, I realised the Author (email) in the last commit was something arbitrary value (something like this ~ psaggu.localhost@private-domain). The bot use the Author (email) value to verify if there is a GitHub username in their record, who have signed the CNCF CLA using this email address. And if there is, then the bot label the PRs from this user as cncf-cla:yes, otherwise cncf-cla:no(leaving one of the required PR workflow test failing). Now, I knew the problem but I still wasn’t sure how to fix it. So, with some more tinkering on internet, this article came to my rescue. And more precisely this command: git commit --amend --author="John Doe <john-doe@example.com>"

  • That’s it, ammending the previous commit with the --author flag worked for me & the bot (fortunately) changed the label to cncf-cla:yes. Also to note, I spent some time with the Linux Foundation Jira board as well, checking if I could create a case there, but that was extremly slow & I literally closed the tab only after trying for 4/5 times (good for me).

So, on and all, today was more of a git learning with all other stuff I did.

More tomorrow, bye!

Other posts