The files in /usr/etc are mounted from the updated ostree image. They are there as the source for creating a new /etcdir if it does not exist. There are rules as to how a merge happens upon ostree update. I summarized (and linked to the original docs) in the article below.
TL;DR - once /etc is created if a file is modified as compared to its counterpart in /usr/etc it is not touched. There is detection guidance linked to in the article.
That is for the consumer host. But, you have a custom image. So, in theory, you should be able to partially manage these changes as part of your CI/CD pipeline in GitHub. But there may need to be some cooperating conversion on the consuming host as well - to address the changes to user / group id’s or names. E.g., to convert perms of dirs, files, etc.
That’s the theory I can help with. Hopefully someone who manages a custom image can offer a practical solution.
It would be good to understand what the reason is that ids in /usr/etc/{passwd,group} do change over time.
In other words: when I install, e.g. opensmtpd in my custom image, the install process presumably decides which ids the smtpq resp. smtpd users/groups get assigned. I have no idea why this changes sometimes when a custom image gets built.
Is the order you are installing opensmtpd staying in the same position in terms of build order? Think about how UIDs are picked … first come, first served within each range of system vs user UIDs.
E.g., if you add a new rpm install, you might want to make sure you add it after any existing installs. But I am not sure what bluefin is committing to along the lines of their template in terms of which range they reserve for custom images - if any.
I notice that both the UID and GID of smtpq went from 946 to 947 which rippled through the rest. That suggests to me that in the second example something else was installed before opensmtpd that picked 946. Although I do not see evidence of that in your snippets.
I also wonder if GitHub action caching is getting in your way. Doesn’t seem probable based on what you are showing … but something I have run into with installing python pip modules, etc. where my understanding of the current state of the build was wrong.
Do you have caching enabled in a GitHub action somewhere? My issue was related to gcc building of cpython extensions built when installing a pip module. I had to explicitly delete the current cache for python 3.12 which seemed unrelated. But once I saw that worked, it was just a matter of finding the right place in my test.yml workflow file to turn off the use of caching. Things started to become more repeatable.
Point is - if you get stuck again - try to delete GitHub action caches you may have one at a time to see if you get a better clue.
Also, I am not sure which OS component stores the “next available UID” now a days - PAM, NSS? But finding a way to output that info in a few places of your build.log before installing opensmtpd might help as well.
, and I will watch if something gets changed nevertheless over the next time.