fix: add missing container tags

[xynydev]

I just built & published my image with the tool and noticed there are some differences to startingpoint with the generated tags

• There's a commit hash tag, that's cool
  • It shouldn't need the -latest suffix, though. And another tag had latest as a prefix, hmm.
• Major version tags are missing (38, 39)
  • Also version-date and version-commit
• Latest date tags are named differently 20240122 (startingpoint) vs latest-20240122 (bluebuild)

[bayou-brogrammer]

Do we not want to include latest to just be more verbose? I always side with explicit over implicit

[gmpinder]

What branch do you build on? Cause I hardcoded it to look for the live branch while I was getting it thrown together for GitHub.

[gmpinder]

Major version tags are missing (38, 39)

OH! I think it's because I'm using the version that's defined in the recipe yaml. I guess we would need to add logic to pull info from the base image to determine the proper fedora version huh?

[gmpinder]

This seems to be tied to blue-build/github-action#2

[xynydev]

Major version tags are missing (38, 39)

OH! I think it's because I'm using the version that's defined in the recipe yaml. I guess we would need to add logic to pull info from the base image to determine the proper fedora version huh?

Yeah, the info should be in /etc/os-release, but I'm not sure how that translates to other distros.

What branch do you build on? Cause I hardcoded it to look for the live branch while I was getting it thrown together for GitHub.

I think for new templates we want to lose the live/template branch structure, since the new reusable github action will handle all the updates in features. I'm not sure where you hardcoded this?

[xynydev]

Ok, I found the part where live is hardcoded. Didn't know the tags were generated in template.rs. I guess you should change it to support either live or main branch to support both the old and new plans.

[gmpinder]

So with Gitlab CI, they have an env var to tell your pipeline what branch is the default branch. If I can find that var for Github, that would be a good replacement

[bayou-brogrammer]

GitHub allows for environment variables. Go to settings, secrets/keys and it should be an environment option

[xynydev]

Forgot to respond to this

Do we not want to include latest to just be more verbose? I always side with explicit over implicit.

I was just thinking abt how startingpoint does things and keeping parity. Another argument is: latest should always mean latest version and date-latest might be contradicting. And of course the tags always pull the latest image with that tag, that's the point. :39 is the latest version of 39, so why wouldn't :20240101 be the latest version from that date? If one wants, they could specify a different version though, like :38-20240101. But the point of :latest is to roll over to the next version automatically, so I don't see the point of :date-latest.

[gmpinder]

GitHub allows for environment variables. Go to settings, secrets/keys and it should be an environment option

I was talking about the built in variables set by GitHub actions. I can look it up later

[gmpinder]

From conversations in the Discord:

• check if branch is live or main
• put image_version on the end of tags
• Add a timestamp tag
• Detect actual OS version and use that in place of recipe's image_version

[bayou-brogrammer]

What should the the timestamp be formatted as?

[xynydev]

What should the the timestamp be formatted as?

Same as now, YYYYMMDD.