📦 Creating nightly release on master push

[sschleemilch]

Creating a gh-release tagged as nightly with *.whl added as asset on every master push.
Even it is not built nightly but on a master push, nightly represents best what the content is. The latest master branch as a wheel.
If we want to get a bit cleaner here I would vote for maintaining CHANGELOG.md on every PR and bumping the version in pyproject.toml accordingly based on the change that has been done. Then we can create real pre-releases for every version ending on master.

The latest nightly wheel can then be downloaded via:

curl -L https://github.com/COVESA/vss-tools/releases/download/nightly/vss_tools-nightly-py3-none-any.whl -O

[erikbosch]

I like the idea. I was just thinking of the name "nightly", as this file as of today does not really run nightly (with cron) but rather only on merge of pull requests.

(Theoretically we may get regressions even without changes in our repo, like if an action gets outdated or updated without changing major version)

Alternatives:

• Keep it as is (works for me)
• Use some other name/tag than "nightly"?
• Add a cron as well so it runs nightly as well?

[sschleemilch]

True, I was also playing with the wording. Nightly is technically not completely correct as you correctly mentioned since it is triggered on master pushes. How about latest? The problem I have with latest is that it usually means latest release but we are not talking about a release here

[sschleemilch]

Changed trigger to schedule at midnight and therefore making it a real nightly

[SebastianSchildt]

it seems a bit waste to build "nightly", if nothing haopens you build the aame thing over and over again, if somebody wants to test something, and is not inclined to build the wheel he needs to sleep the night.

I think something like

on:
  push:
    branches: [ main ]

would be better. Can just call it "dev" ("latest" not goot that would imply a stable version)

[SebastianSchildt]

An actually, I think it shoudl even build on PRs but then not create a release but just archive the wheel . Again, to give people somehting to test

Something like (not tested)

- name: "Uploading  artifacts"
      uses: actions/upload-artifact@v4
      with:
          name: vss-tools-${{ github.sha }}
          path: dist/*.whl
          if-no-files-found: error

[erikbosch]

An actually, I think it shoudl even build on PRs but then not create a release but just archive the wheel . Again, to give people somehting to test

Something like (not tested)

- name: "Uploading  artifacts"
      uses: actions/upload-artifact@v4
      with:
          name: vss-tools-${{ github.sha }}
          path: dist/*.whl
          if-no-files-found: error

I guess that depends on how you intend to use the wheel. If someone downstream (Kuksa, BMW, anyone, ...) actually wants to test with the "latest wheel" on possibly nightly basis a release has the advantage that it gives a static link, compared to builds.

[sschleemilch]

An actually, I think it shoudl even build on PRs but then not create a release but just archive the wheel . Again, to give people somehting to test

Something like (not tested)

- name: "Uploading  artifacts"
      uses: actions/upload-artifact@v4
      with:
          name: vss-tools-${{ github.sha }}
          path: dist/*.whl
          if-no-files-found: error

On PRs I do not think it will be that useful. People reviewing PRs probably know how to checkout a PR branch and do poetry install. I think downloading a wheel and then doing pip install on it is also not less effort. And as Erik said, build artifact URLs are not static.

However, I agree that a nightly schedule is overkill since it would nearly never change.
So I went back to a trigger on master.
Only thing left is name of the tag. From a user perspective the expected content would be nightly even though it is not built every night. That's what I put now. Or maybe wheel? 🛞

[erikbosch]

LGTM. Lets make a merge decision tonight

[sschleemilch]

After merging that we can extend the vss-tools readme how to install the nightly via pip

[erikbosch]

MoM:

• Merge
• AP: Erik/Sebastian to check that it works after merge

[sschleemilch]

After thinking about it: do you think it will really increase value for Users?

[sschleemilch]

To be reopened when needed