Upload release assets

[cdce8p]

Proposed change

Add CI job to upload sdist and wheel as release assets. This will provide an alternative for the users who depended on the sdist which is no longer uploaded to PyPI. All officially supported install methods work fine with the provided wheel.

I've tested the workflow on my personal fork extensively, so I'm confident that it should work. To know for certain though, we'll have to wait for the next release.

Fixes: #11542

/CC: @bramkragten @frenck

Depends on

• Add release-assets action actions#61

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New feature (thank you!)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Example configuration

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue or discussion:
• Link to documentation pull request:

Checklist

• The code change is tested and works locally.
• There is no commented out code in this PR.
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

[bramkragten]

LGTM, but no github action expert

[ludeeus]

Needs an adjustment
However, I don't think we should add this workaround as it goes against our ADR (0012)
https://github.com/home-assistant/architecture/blob/master/adr/0012-define-supported-installation-method.md#decision

We are open for contributions that improve compatibility with a community-supported method as long as they do not impact officially supported methods, add a significant amount of code exceptions or future maintenance burden on the Home Assistant development team.

This will additional maintenance we do now have for our supported installation methods.

[cdce8p]

Needs an adjustment However, I don't think we should add this workaround as it goes against our ADR (0012) https://github.com/home-assistant/architecture/blob/master/adr/0012-define-supported-installation-method.md#decision

We are open for contributions that improve compatibility with a community-supported method as long as they do not impact officially supported methods, add a significant amount of code exceptions or future maintenance burden on the Home Assistant development team.

This will additional maintenance we do now have for our supported installation methods.

I would argue that the maintenance requirements are quite low once it's up and running. Furthermore, the original plan was to upload both sdists and wheels to PyPI. The only reason we had to change that plan were space constraints, it just adds up quickly to upload twice the amount of data each time.
Usually it's good practice for a package to provide both since some package manager require sdists. It also has become more and more common to add the artifacts as assets to the release notes. Especially for a project where compiling them takes more then 1-2min.

Lastly, I'll provide a good archive storage for us. We needed to delete some releases from PyPI recently due to the before mentioned space constraints. If we would want to upload them again once the limit is increased, we would have to build each tag from scratch. That's just unfeasible.

[cdce8p]

I've created a composite action which would help simplify the changes here. It would also allow us to reuse it in Core eventually if we want to. home-assistant/actions#61

[balloob]

I want to move forward with this PR.

Reasoning is that translations are outputted during build time. By only storing them on PyPI inside a wheel, we don't have a single source of truth of the package.

This PR would solve that.

[cdce8p]

Tested the change again, against my own fork. Everything worked as expected, so this PR could be merged.

[cdce8p]

Thanks @frenck for the suggestion! I've replace the existing code to use the softprops/action-gh-release action instead.
https://github.com/marketplace/actions/gh-release#%EF%B8%8F-uploading-release-assets

Example log output

♻️ Deleting previously uploaded asset home_assistant_frontend-20220205.0-py3-none-any.whl...
♻️ Deleting previously uploaded asset home-assistant-frontend-20220205.0.tar.gz...
⬆️ Uploading home_assistant_frontend-20220205.0-py3-none-any.whl...
⬆️ Uploading home-assistant-frontend-20220205.0.tar.gz...
🎉 Release ready at https://github.com/cdce8p/ha-frontend/releases/tag/v0.5.1

[ludeeus]

Suggested change

	permissions:
	contents: write # Required to upload release assets

It already have this?
https://github.com/home-assistant/frontend/runs/5578172811?check_suite_focus=true#step:1:16

[cdce8p]

It's recommended to limit the permissions to what's necessary.
https://docs.github.com/en/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token

As a good security practice, you should grant the GITHUB_TOKEN the least required access.

By adding only contents: write explicitly, I exclude all other permission scopes.

[ludeeus]

If that is the reason behind it, it should be defined on the workflow as read, and then open each job to what they need.

[cdce8p]

31cc0a1 I checked the other jobs. None need additional permissions.
I wasn't sure about artifact upload / download, but after testing it seems to work just fine.

For the future, it might be worth considering to limit the default repo¹ / org² permissions for Github tokens.
With regards to the other workflows, only a few would need explicit permissions.

• release-drafter -> contents: write to create pre-releases
• lock³ and stale⁴ -> issues: write and pull-requests: write

Footnotes

1. https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#setting-the-permissions-of-the-github_token-for-your-repository ↩

2. https://docs.github.com/en/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#setting-the-permissions-of-the-github_token-for-your-organization ↩

3. https://github.com/dessant/lock-threads#examples ↩

4. https://github.com/actions/stale#recommended-permissions ↩

[ludeeus]

Uploading action artifacts needed "deployment" before, but if it works without anything that's just great 👍
As for changing the default of the entire org, I 100% agree with that, both in regards to the token, and potentially implementing an allow list for approved actions.

[cdce8p]

Just to make sure, could someone check that third party actions are allowed in the repository settings? Or at least add softprops/action-gh-release to the allow list?
https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-specific-actions-to-run

[frenck]

@cdce8p Works.

[ludeeus]

LGTM