Feature authorship: One per git project kind of sound supported?

[aservedio]

Hello, I have been getting happily getting into Features and I have a few I want to create.

Now I try my best not to bundle parts of code together if they don't need to be. Divide to conquer kind of thing. So that's the angle I took first, trying to create one git project per feature, and use git tags as feature versions.

I got it working.. but it feels like I'm fighting against the system or I am not doing it right.

• The documentation on containers.dev is worded in a way that seems like you can have 1 feature per git project but without any details of that.
• The devcontainer-cli seems to work and be aware when asked to package/publish a single feature or a collection of features.
• Features have versions, but it's not clear to me how those versions are expected to get bumped in a collection. Seems untied to any source code tags. (at the moment I just use 0.0.0 in the json file and use sed replace in pipeline before publishing)
• devcontainer cli features test, this one seems to really not want to work with anything else then a collection structured as src/pkgName and test/pkgName. Anyway to make that work in a single repo mode where src/ is the feature and test/ is that feature test?

Any clarity on the above would be appreciated, here or maybe in the docs. I cannot be the only one that would naturally try to split those features into different projects :P

Thanks!

[joshspicer]

Hey 👋

Thanks for highlighting this. As you discovered, the Dev Container CLI should be able to auto-detect and publish a single Feature if the repository is structured as such ref.

That said, I just tested it out and it looks like the GitHub Action and the test command currently assume structuring the with the src and test folders.

This is something we should fix across the set of the tools used for publishing and testing. I'll make issues and link to this one for you to track.

Features have versions, but it's not clear to me how those versions are expected to get bumped in a collection. Seems untied to any source code tags. (at the moment I just use 0.0.0 in the json file and use sed replace in pipeline before publishing)

In the devcontainers/features repo, we manually update the version property for each Feature when we make a change. Doing something like you're doing now makes a lot of sense. In the future, it might make sense to have the tooling auto-increment the version, but today we do that manually (so using sed as you are doing makes sense to me!)

[aservedio]

Thanks for the update! Looking forward to trying it out.

For the auto-increment part of it, I'm a big +1 on giving workflow flexibility on this one, kind of like what helm cli does among others, where it will pickup version from specifications in some file, but that you can also provide yourself if you want the helm release tag to match a git project tag.

That being said, I understand better now how the cli auto-handles publishing X.Y.Z, X.Y, and X automatically, and the advantages the collection part of it can bring. So that flexibility I had in mind in my initial post, is probably not as simple as I imagined.

I'll just keep the sed way for now on that front and see how it goes in the future.