Make it more clear when something new is installed on a hosted agent

[dlemstra]

As of today I am watching the release notes to see when a change to a hosted build agent is made. I need to do this because sometimes something new gets installed on the agent that breaks my build process because I first had to manually install it. Would it be possible to make it more clear when something gets updated or when something new gets installed on the agent in the release notes?

[miketimofeev]

Hi @dlemstra!
Could you provide a few examples, please? I'm asking because release notes already contain updated\added software and nothing more

[miketimofeev]

I got your point. You would like to see something like, correct?

Tools

• 7zip 21.07 [Updated]
• Newman 5.3.1 [Updated]
• Pulumi v3.22.1 [Updated]
• Service Fabric SDK 8.2.1363.9590 [Added]
• zstd 1.5.1 [Updated]

[dlemstra]

Yup, something like this. That would make it more clear for me to take action when something is added that I manually install.

[miketimofeev]

Sounds reasonable, thanks for the idea! We will investigate such a possibility but I'm afraid I can't provide any ETA now as we have more prioritized tasks at the moment

[dlemstra]

Thanks for considering to add this!

[Kurt-von-Laven]

ScribeMD/rootless-docker#75, ScribeMD/rootless-docker#81, ScribeMD/rootless-docker#82, ScribeMD/rootless-docker#83, and ScribeMD/rootless-docker#84 are all examples of fixes (or attempted fixes) that would have been simplified by the availability of more detailed release notes mentioning the PRs being released along with brief summaries of their nature. On June 26th, something started setting $XDG_RUNTIME_DIR to /run/user/1001, and Docker stopped creating /home/runner/.docker/run; perhaps this was caused by #5812? On July 10th, rootless Docker began detecting systemd (changing the behavior of its install script), and the rootful and rootless Docker daemons became capable of detecting each other (meaning they could no longer run side-by-side). This also sounds potentially related to #5812 at face value, but I am not sure why we wouldn't have experienced the effect sooner. In any case, it would be good to call out changes to environment variables, and that seems like something that could be automated. We would certainly want to know when the configuration of something as major as systemd was modified, which would have been covered by mentioning the PRs in this case. Having more readily available details of the changes contained in each release would be especially helpful since the releases are rolled out incrementally (meaning during that time we saw some successes and some failures depending on which version of the image we were on), and there's no way to pin or roll back to a specific release of a GitHub-hosted runner image.