sort the packages versions alphabetically

[sparklyballs]

somewhere in this block

https://github.com/linuxserver/docker-jenkins-builder/blob/master/roles/generate-jenkins/templates/Jenkinsfile.j2#L514

there needs to

sort -o /tmp/package_versions.txt  /tmp/package_versions.txt

especially so on the alpine side , to make the resulting file in the target github repo a whole lot more readable.

[thelamer]

Yeah good idea, do you see anything else you don't like?

Only bring it up because changes like this waterfall to all 100+ repos, so if we are gonna make some logic changes it is nice to piggyback other stuff on.

The implementation was like this because I figured we only cared about the diffs on actual changes to trace a new bug not the actual presentation of the file.

[sparklyballs]

i can't see any linting (shellchecking) on any files in the images.

[thelamer]

I'm down with a linting step as long as we can get back soft warnings somehow. Just worried about the current state of the codebase across all repos. Don't want to put it all into an error state until we can manually go in and clean it up.

[sparklyballs]

i think having the package name, then the package name again with the version seems redundant

with alpine for instance

libressl2.7-libssl libressl2.7-libssl-2.7.5-r0

[sparklyballs]

you can just have it spit out a report and take no action f there are errors

https://ci.sparklyballs.com:9443/job/Docker-Builds/job/beetstest/

not sure how you get that with jenkinsfile scripting but it should be possible. ignore the hadolint , that shellchecks docker files , and meh as to usefulness tbh

[sparklyballs]

and this could make a more readable output for the ubuntu package version list

apt list -qq --installed | sed "s#/.*now ##g" | cut -d ' ' -f 1

[thelamer]

First off changes to the template, you can loop test stuff on the currently stale testing branch here:

https://github.com/linuxserver/docker-jenkins-builder/blob/testing/roles/generate-jenkins/templates/Jenkinsfile.j2

This will perform the templating and package change commits in repo for loop tests. Unfortunately this repo is Alpine only so it will not cover loop testing Ubuntu changes. Once you know stuff is gonna work how you like it you can PR into master.

That is not to say I am telling you do X or Y, just pointing out the process if you are interested.

I have to admit I just ran through hadolint and dockerlint locally and their errors do not make sense to me. Stylistically dockerlint just spits out shit that we do that they might not agree with and hadolint complains about some weird stuff along with their line referencing just points to the origin run command not actual lines. I get that compilation and functionality testing does not cover code style, but I am not 100% on where to integrate this in the build process that will produce useful output to the team. If we lock it up in the build logs no one will ever look at it, the CI process is a Python app and appending stuff to it's report in general needs to be done through Python (https://github.com/linuxserver/docker-ci/blob/master/ci/ci.py). Storing it in Git would cause uneeded image pushes on errors then subsequent pushes. The only remotely viable I can think of would be to:

• run linting in a build step that force exits zero writing the output to a file
• the linting report is pushed to object storage using this container https://github.com/linuxserver/spaces-file-upload (we use this for the picons push)
• the file is named something unique before upload and that link is send in the discord status ping in addition to the current links

Still though it all comes back to if we are not enforcing the style then why are we linting during the building.

[sparklyballs]

realistically hadolint is a non-starter for us, some of the warnings make sense as it shares most of them with shellcheck, but others are weird.

but shellcheck makes much more sense, it's saved our bacon a couple of times at least with some unseen outcome of a bash script in the init files, especially with globbing and if statements.

reporting could be confined to jenkins , but i'm really not sure how that would work with the jenkinsfile system. with the old style build jobs that i'm using, (but with the newer report aggregation plugin https://wiki.jenkins.io/display/JENKINS/Warnings+Next+Generation+Plugin ) , the results can be pulled together into the linting tab on the ci main page.

whether or not though keeping it in jenkins is the best idea is obviously up for debate, i only outlined the above cos that is the current model.

enforcement would be by way of manually changing any reported warnings.