changes the means to compute the version for packages #499
Conversation
cmickeyb
force-pushed
the
mic.oct03.version
branch
from
eb82ca7 to
2c1585f
Compare
Hmm, if we tag that version-update commit, why do we still need a VERSION file and that commit and do not just use the tag? Seems to me we really should use only one or the other (VERSION file or tag) to reduce confusion (in particular given that commit in VERSION file is by definition (at least) one commit version before the tag?) Also, if we maintain the VERSION file, maybe it would be good to have a script which updates it based on current commit and a version provided to script and right away commits? Besides being convenient it would ensure consistency? |
the version file should be authoritative. the version tag should just be for retrieving the commit where the version file changed. this can be automated (in theory) with a github workflow. in practice, this appears harder than it looks. |
Creating a script (parameterized by new version) in repo which updates VERSION, commits & tags could be an easy poor-man's version of the github workflow? No matter what, a version update has to be executed manually so calling that script in your local repo is arguably even simpler than going to the repo web UI and trigger some workflow? |
Its reasonable to have a script to create the version. But there is a catch-22 here. You can't tag a version that you don't have. The workflow is probably the right way to do it in the long run. In the short term, we have to have a legitimate version. And everything we currently build in github is 0.0.0 (which means there is no way to use GHCR to store and retrieve the images). |
cmickeyb
force-pushed
the
mic.oct03.version
branch
2 times, most recently
from
59240aa to
8a77086
Compare
@g2flyer i've added a "set_version" script that can be used to update the version file. at this point i think the PR is ready. |
Not sure i understand: what i was thinking is something along the lines of your set_version which updates the version file but then also does right away the commit (because as you said in desc and i agree that version update should be in standalone commit); in that case you could tag afterwards (and as long as you do a merge commit in PR or a rebase from top-of-master/main then the tag should be the right now? Doing commit & tag in script also has advantage that we can enforce that commit is exactly and only the version file update as you suggested above (and i certainly agree). |
| @@ -8,7 +8,7 @@ jobs: | |||
| pdo_ci: | |||
| if: "!contains(github.event.commits[0].message, '[skip ci]')" | |||
| name: PDO CI Job | |||
| runs-on: ubuntu-20.04 | |||
| runs-on: ubuntu-22.04 | |||
There was a problem hiding this comment.
Hmm, according to our docs, 20.04 is still the default. If we change it here maybe we should change it also there? And if change, why not change straight away to the latest LTS, 24.04?
There was a problem hiding this comment.
remember that this is the version only used for building the docker images. nothing else runs here. so its not actually related to our documented default version. i could go for a jump to 24.04 if that actually makes a difference. only wanted this for improved docker commands.
…e this Version information is kept in the file VERSION. The file contains lines for each version from the most recent to the most distant. Each tab separated line contains a version (of the form v?[0-9]+.[0-9]+.[0-9]+) and the hash of a git commit that represents that version. Each line may also have a short description separated by a tab. When a new version is committed, only the VERSION file should be modified and the commit should be tagged (annotated tag) with the version number. This also required some changes to the github workflow to pull the full history of the repository (otherwise the patch level of the version cannot be computed). Signed-off-by: Mic Bowman <mic.bowman@intel.com> Apply suggestions from code review Co-authored-by: Michael Steiner <michael.steiner@intel.com> Signed-off-by: Mic Bowman <cmickeyb@gmail.com>
Note that trivy notes errors about missing USER declarations. The final images that are built, pdo_ccf, pdo_services, and pdo_client all have users defined. Signed-off-by: Mic Bowman <mic.bowman@intel.com>
cmickeyb
force-pushed
the
mic.oct03.version
branch
from
7f1ee98 to
c4841ee
Compare
Change the way we compute the version so that github workflows can use this
Version information is kept in the file VERSION. The file contains lines for each version from the most recent to the most distant. Each tab separated line contains a version (of the form v?[0-9]+.[0-9]+.[0-9]+) and the hash of a git commit that represents that version. Each line may also have a short description separated by a tab.
When a new version is committed, only the VERSION file should be modified and the commit should be tagged (annotated tag) with the version number.