search

dlang-community / setup-dlang

Github action for dlang compiler setup
MIT License
46 stars 14 forks source link

binaries: remove generated node_modules binaries and compiled .js files #42

Closed ljmf00 closed 3 years ago

ljmf00 commented 3 years ago

Signed-off-by: Luís Ferreira contact@lsferreira.net

ljmf00 commented 3 years ago

Closing this. Javascript and this Github action integration is just bad :(

WebFreak001 commented 3 years ago

the node_modules is required by github actions, it doesn't do an install

ljmf00 commented 3 years ago

the node_modules is required by GitHub actions, it doesn't do an install

Yes. A better way would be to bundle only the required stuff from the dependencies in a file and have a developing branch and then deploy the generated files the actual action to the release branches (v1, v2, ...)

mihails-strasuns commented 3 years ago

Each PR branch is effectively a separate devel branch, so this is effectively how it works already. We have agreed to switch node_modules to a bundled version though, so it is only a matter of someone doing the implementation (would be cool to do it automatically on a PR merge).

ljmf00 commented 3 years ago

Each PR branch is effectively a separate devel branch, so this is effectively how it works already. We have agreed to switch node_modules to a bundled version though, so it is only a matter of someone doing the implementation (would be cool to do it automatically on a PR merge).

What I was trying to say is having a development branch in the upstream instead of pushing directly to version branches or changing tags, this is generally a bad practice because changing a version, for whatever reasons is bad. When a user relies on a version, that version shouldn't change, and therefore, the upstream branch related to that version shouldn't change too.

mihails-strasuns commented 3 years ago

But a version is a tag. If you depend on untagged version branch in your yml, you are explicitly opting in for the latest version of that branch. I could understand the concern if there was any additional stabilization stage needed, but for setup-dlang anything that is good enough to pass CI in PR, is good enough to be immediately released (and there is no extra verification involved).

PetarKirov commented 3 years ago

@ljmf00 btw I fixed this issue in #43

ljmf00 commented 3 years ago

@ljmf00 btw I fixed this issue in #43

Thanks :+1:

ljmf00 commented 3 years ago

But a version is a tag. If you depend on untagged version branch in your yml, you are explicitly opting in for the latest version of that branch. I could understand the concern if there was any additional stabilization stage needed, but for setup-dlang anything that is good enough to pass CI in PR, is good enough to be immediately released (and there is no extra verification involved).

Oh, ok screw that part then. I completely missed the fact that this repo is being tagged.