Problem/Motivation

I built my add-on following this structure which is awesome. For the release-drafter though, I created my own very simple template. I am wondering where the template of this and other add-ons in this organisation are located, since I cannot find it in any add-on and also not in the workflow repository.

Expected behavior

Would have expected a release-drafter.yml in .github int eh repository or at least in the workflow repository

Actual behavior

Cannot find any in the whole organisation

Problem/Motivation

I can install the example addon from the default repository via Android without issues (but for some reason, I don't see it on the PC web page?). But when I copy just the example folder to my own repository I get an error when I try to install. I also get the same error on one other repository that also uses some of the example as a base. sdesalve/hassio-addons#32

Expected behavior

installed the addon from my own repository just like from the default repository

Actual behavior

The command '/bin/ash -o pipefail -c apk add --no-cache coreutils=8.32-r2 wget=1.21.1-r1' returned a non-zero code: 2

Steps to reproduce

I'm using Linux Mint 19 and I did clone my and the example repository to my local drive. Next, I copied just the example folder from this cloned repository to my cloned repository. Last I push everything for my repository back to Github. In the addon store I do a reload and then I select install from my repository. I get the error and some more red text in the log.

System

System: Raspbian GNU/Linux 10 (buster) (armv7 / raspberrypi4)
Docker version 20.10.1
Home Assistant Core: 2021.1.4
Home Assistant Supervisor: 2021.01.5
Btw, I was able to install other updates to day like node red and the time server addon without issues.

Problem/Motivation

Trying to learn, but the example is broken

Expected behavior

Log shows quotes

Actual behavior

from plugin log
[12:14:00] INFO: Starting Example2...
./run: line 10: /usr/bin/example2.sh: Permission denied
[12:14:00] INFO: Starting Example1...
./run: line 10: /usr/bin/example1.sh: Permission denied
[12:14:01] INFO: Starting Example2...
./run: line 10: /usr/bin/example2.sh: Permission denied
[12:14:01] INFO: Starting Example1...
./run: line 10: /usr/bin/example1.sh: Permission denied
[12:14:02] INFO: Starting Example2...
./run: line 10: /usr/bin/example2.sh: Permission denied

Steps to reproduce

install plugin

Proposed changes

(If you have a proposed change, workaround or fix,
describe the rationale behind it)

Problem/Motivation

Installation attempt from add-on store produces the following error message:

Pulled image ghcr.io/hassio-addons/example/aarch64:4.5.0 failed on content-trust verification!

Expected behavior

Installation success

Actual behavior

Pulled image ghcr.io/hassio-addons/example/aarch64:4.5.0 failed on content-trust verification!

Steps to reproduce

Click the Install button

Proposed changes

(If you have a proposed change, workaround or fix,
describe the rationale behind it)

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

This repository currently has no open or pending branches.

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Problem/Motivation

Log tells me:

[17:35:42] INFO: Starting Example1... ./run: line 10: /usr/bin/example1.sh: Permission denied [17:35:42] INFO: Starting Example2... ./run: line 10: /usr/bin/example2.sh: Permission denied

I tried to restart, but there was no success for me.
Im using Hass.io 0.103 with a Rasperry Pi 3+.

Maybe someone can help?

Problem/Motivation

This account currently uses a large run.sh script that bootstraps the whole add-on.
Our new base images actually contain the S6 process supervisor, which allows us the split all kinds of different add-on responsibilities in an amazing way.

Additionally, the new base images are equipped with an extensive Bash function library full of tools towards Home Assistant add-ons on S6. This will greatly reduce the amount of code and improve stability overall.

Problem/Motivation

There are several reasons for this:

• Not all log messages are consistent across all add-ons.
• Some messages are unclear to the novice user.

Marking the repository as a template would make it easier to for others to use it as a starting point for new addons:

https://help.github.com/en/articles/creating-a-template-repository
https://help.github.com/en/articles/creating-a-repository-from-a-template

Creating a template repository - GitHub Help

Creating a repository from a template - GitHub Help

Problem/Motivation

I have forked this repository to https://github.com/a2i2/hassio-addon-pubsub and replaced the add-on content with my own. I am using the Actions in .github/workflows to build the add-on.

When I push to the main branch, the Docker cache works perfectly and the build is very quick. However, when I use GitHub Releases to produce a new release/tag, the Docker cache isn't loaded and the build is performed from scratch.

Output of the Set up build cache step:

Run actions/[email protected]
Cache not found for input keys: docker-refs/tags/v0.2.2-aarch64-66ca8825aebfda283e1368507bd197e35314a57a, docker-refs/tags/v0.2.2-aarch64

It looks like the same thing happens with this example repository:

https://github.com/hassio-addons/addon-example/runs/2380713962?check_suite_focus=true

Expected behavior

Docker cache is found and used on tagged releases

Actual behavior

Docker cache is not found on tagged releases; build is performed from scratch and takes a long time

Steps to reproduce

Create a GitHub Release, go to Actions and find the cache step and see message saying no cache was found.

Proposed changes

Not sure what the fix would be. Load the cache from edge?

Problem/Motivation

The example currently uses a Docker CMD instruction to start, which is fine, but that is now how all the other Community add-ons work.

This causes differences in all kinds of forked / add-ons based on this example.

Expected behavior

The example add-on to match the work method used in the Community Add-ons repositories.

Actual behavior

It differs

Proposed changes

Move the current CMD script into a service.

see only this in logs after starting

[20:43:13] INFO: Starting Example1...
./run: line 10: /usr/bin/example1.sh: Permission denied
[20:43:14] INFO: Starting Example2...
./run: line 10: /usr/bin/example2.sh: Permission denied
[20:43:14] INFO: Starting Example1...
./run: line 10: /usr/bin/example1.sh: Permission denied
[20:43:15] INFO: Starting Example2...
./run: line 10: /usr/bin/example2.sh: Permission denied
[20:43:15] INFO: Starting Example1...
./run: line 10: /usr/bin/example1.sh: Permission denied

Problem/Motivation

permission denied executing service scripts following addon template

(in case it matters I'm ussing the addon debian-base, not alpine

Expected behavior

it runs

Actual behavior

./run: line 6: /usr/bin/run_gateway.sh: Permission denied

Steps to reproduce

(How can someone else make/see it happen)

Proposed changes

There was previous discussion on this, but with #126 I didn't see the chmod commands carry over. Adding explicit RUN chmod a+x on my scripts successfully worked past this issue