-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(lint): make testing lint easier #1753
base: master
Are you sure you want to change the base?
feat(lint): make testing lint easier #1753
Conversation
as I created Bash-it#1753 and seperated the dependencies, there is no need for the duplication This reverts [PARTIALLY] commit 026ccfe.
as I created Bash-it#1753 and seperated the dependencies, there is no need for the duplication This reverts [PARTIALLY] commit 026ccfe.
I am unsure about this, as this seems like very opinionated change, but allows developers without all the setup to run the lint stage. However, this sort of thing should be handled by the person wanting to contribute, as people tend to have different opinions about this kind of stuff... |
I am fine with it being changed and generalized based on opinion. This way we can validate the scripts are ok, and make the container mode widely used |
In general, I like the idea of running tools in containers, since it makes it easier to run uncommon tools without having to install all of the dependencies. The tradeoff is that you have to have Docker installed... I'm also careful with using open-sourced containers, e.g. from Docker Hub, since many of them contain security vulnerabilities or malware - we need to be careful to not introduce these issues here. There are some pre-built To me, it feels like these instructions are a better fit for our documentation - I don't see us adding more and more test scripts to the project root, it will get crowded there... |
Hi Team, After grinding on this for a bit, here are my thoughts:
This would provide a basic ability to lint files without having to have pre-commit/shfmt installed locally. The user could get clever and do things like:
|
I am all for what @davidpfarrell said, and I agree with ya'll on the concerns.. should we create a roadmap we agree on for this? I think that:
|
You know, my statement was actually to create a separate container for the pre-commit, ie:
Having it in the same container may also be useful, but I think there's value in a stand-alone container as well. |
created PR Bash-it/bash-it-docker#3 on it, we can do some stuff there and them move back to this one |
Howdy y'all. Great discussion! Here's my $0.02
|
Hey y'all! Can someone TAL to see what I missed so we can proceed with this PR? |
as I created Bash-it#1753 and seperated the dependencies, there is no need for the duplication This reverts [PARTIALLY] commit 026ccfe.
hey! bumping up as it didn't get eyes yet... can you TAL at Bash-it/bash-it-docker#3 ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hey @georgettica, nice work here! I left comments here and in the second PR, you are welcome to take a look 😄
@@ -0,0 +1,6 @@ | |||
#!/bin/bash | |||
|
|||
CONTAINER_ENGINE=${CONTAINER_ENGINE:-docker} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would place this script somewhere in the docs, so ppl will know that they can use it
@@ -0,0 +1,6 @@ | |||
#!/bin/bash | |||
|
|||
CONTAINER_ENGINE=${CONTAINER_ENGINE:-docker} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably note that this variable exists and how to use it in the same doc
|
||
CONTAINER_ENGINE=${CONTAINER_ENGINE:-docker} | ||
|
||
${CONTAINER_ENGINE} build --file ./testing.Dockerfile --tag test . |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no need to build the docker each time- lets just use one we will publish ourselves
@@ -0,0 +1,12 @@ | |||
FROM fedora |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so should we use this dockerfile or the one in the other repo? this one is more minimal...
I vote that we will use this one, just put this in here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason I have 2 is this one is based on fedora and is a little heavier, and the other is an alpine with only the requirements.
But I am glad to move to this as it's my go-to container as of late
related to #1743