Github Codespaces configuration in addons repo

Development IDE & Build
1

I would like to gauge the interest and appetite for supporting development of addons (although this could also apply to core and other openHAB repos) in a GitHub Codespace.

I’ve made a start on a contribution which would enable the provisioning of a GitHub Codespace ready to work on the addon of your choice.

It’s worked well for me working on a binding recently which interacts with a cloud service. At a click I’ve had a VS Code environment ready for me to code in, run a version of the distro to test on, and then submit or update my PR. Clearly a lot of openHAB development needs to be tested against devices on a local network - I think this would be feasible using the GitHub CLI network bridge, but I’ve not tried yet.

I’m sure there’s more work to do, e.g.

  • select an addon to build
  • polish the tasks / build scripts
  • ensure an appropriate version of distro is used

I guess I’m concerned if it’s likely to be accepted in a PR before I put more effort into it:

  • Previous PRs for Codespace like tools haven’t been merged, although at a glance they appear to have been a marketing effort more than a community need - to be clear I don’t have any personal links to GitHub.
  • More generally, do we have any rules or opinions around putting IDE specific configuration in the repo? I’ve not seen any to date, but I wonder if that’s because it’s not been as necessary as it might be for the Codespaces dev pattern.

Any thoughts?

2

How would the pricing work for it? Does each individual developer get their own 60 hours a month free and then need to pay beyond that or would someone need to take on that cost for the whole project?

I’m not sure this would be an allowable expense for the openHAB Foundation.

3

Sorry - cost is an important point!

No need for any cost to the foundation. From what I can see the default is that the user pays for it, there’s a GitHub setting which says any codespaces from the repo are charged to the individual creating / using it. I was also running it against my fork and assume that would default to my account (and I would expect most other devs work on forks?).

For individuals it obviously depends what you are doing. The free tier of 120 core hours per month has been plenty for me doing a few enhancements to a binding over a few evenings.

Edit:
here’s the more explicit answer to your question: the default is that for a fork the usage is billed to the user unless configured otherwise. I’ve not seen anything to suggest that the free tier would be capped per repo as well as per user.

1 Like
4

For casual devs it maybe useful as well as if you don’t have your powerful development PC with you or when it breaks. :wink:

Is it possible to have a config that works with both Codespaces and GitPod?

See also:

2 Likes
5

To my knowledge GitHub Codespaces and VS Code DevContainer are the same technology. Both - for example - definable in form of a devcontainer.json file.

Wouldn’t it make more sense to define the openHAB dev environment via a devcontainer.json and such open the option to run it as local dev environment?

I would guess that an openHAB dev environment is not really that resource intensive? The main advantage would be to have a tested and well defined dev environment preconfigured with sensible defaults?

EDIT: I see that @jamesmelville’s contribution is a devcontainer.json - so it should be usable as local VS Code DevContainer?

2 Likes
6

Thanks for the pointer to that post @wborn - it looks like @FloSchl had got to the same point I did but with Gitpod.

What I’ve done is not re-useable with Gitpod, but per @fex it does seem that the devcontainer.json is a standard which can be used both locally in a VS code devcontainer, plus in some other cloud ~“IDE as a service” tools (at least mentioned in this comparison is another - devpod), as well as Github Codespaces. With the profile of typical bindings being on a local network, running a local devcontainer looks very valuable (docker networking ignored!)

So actually - the setup in that commit might be better described as mostly VS Code specific - much of it cribbed from the existing setup guide. And seeing that config described in an article rather than built into the repo is probably the crux of my question here - is there a reason we don’t include IDE or environment specific configuration in the repo? We do for our hosting / CI process (e.g. the items in .github), so I wonder if there’s any harm in also moving down the chain to the IDE?

I know personally I’d be able to contribute more if I could reliably spin up an up to date development environment as and when I needed one. It doesn’t have to be restricted to what I’ve done here (e.g. we could also support Gitpod, and also potentially expand to other IDEs, e.g Jetbrains), but this feels like a start?

2 Likes