Closed joanlopez closed 6 months ago
As we're at it, I thought of renaming the webpack
command to build
, to align it with what I've observed in the ecosystem. It's a rather small change I believe, but it would also help "hide" that we rely on webpack which feels like an implementation detail.
What do you think?
As we're at it, I thought of renaming the
webpack
command tobuild
, to align it with what I've observed in the ecosystem. It's a rather small change I believe, but it would also help "hide" that we rely on webpack which feels like an implementation detail.What do you think?
I prepared that in the first pull request I prepared around this, but then I did care less because in this second approach the folder isn't being versioned at all. But yeah, it's a minor but fair change, that I can easily add in this pull request. Thanks!
Hey @olegbespalov, @oleiade,
After our discussion, and as per what's commented in https://github.com/grafana/k6-jslib-aws/pull/89#discussion_r1441580456, I decided to update this pull request to just add the release workflow, so at least we can turn that step into a 1-click automation (it just requires creating the tag) and move on.
Wdyt?
~In order to align this jslib with what was discussed (and consensuated) for k6-jslib-summary, and set up here, this pull request:~ ~- Removes the
build
directory from control versioned files, in favor of automated releases~ ~- Sets up a GH Workflow to automate releases from Git tags push.~ ~- Updates the contribution guidelines accordingly.~UPDATE (08/01)
It adds a new GitHub Workflow aiming the (future) automation of releases, heavily inspired by https://github.com/grafana/k6-jslib-summary/blob/main/.github/workflows/release.yml, but using Webpack & NPM instead of Yarn to adjust it to the project needs.
I left some comments in form of open questions inline.