Skip to content
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

Provide more short way to install dotenv-linter #220

Merged
merged 16 commits into from Jul 8, 2020
Merged

Provide more short way to install dotenv-linter #220

merged 16 commits into from Jul 8, 2020

Conversation

DDtKey
Copy link
Member

@DDtKey DDtKey commented Jun 23, 2020

Implemented a script for more short way to install dotenv-linter (#112).

The advantage of the solution is its cross-platform.
The script is executed with curl/wget and even under Windows (checked on MINGW).

Complexity is the process of automatically declaring an environment variable. In some cases, this is only possible manually at the moment.

This is a working version, I also tested on Alpine Linux.

But I would like to hear any ideas for improving or changing the approach.

Perhaps when we come to a final decision, it makes sense to create a separate repository.
Although for installing binaries with a script, it looks suitable in this repo, so far it is not more than 1 file.

✔ Checklist:

  • This PR has been added to CHANGELOG.md (at the top of the list);
  • Docs have been added / updated (for bug fixes / features).

@DDtKey
Copy link
Member Author

DDtKey commented Jun 23, 2020

One option is to install dotenv-linter at the system level(/opt/dotenv-linter for example) and create a symlink in /usr/local/bin.
This will work without any export of variables at different shell levels.

But it will require the user rights to sudo. It will be more difficult for users to override the version only for themselves, and, unfortunately, such a scenario will have many exceptions for Windows 🤔

@DDtKey DDtKey linked an issue Jun 23, 2020 that may be closed by this pull request
@mstruebing
Copy link
Member

Very nice work, thank you, unfortunately I'm a bit low on time right now. But I will have a detailed look soonish, at latest this weekend. 🚀

@mgrachev
Copy link
Member

@DDtKey That's awesome! Thank you! 🔥

@DDtKey
Copy link
Member Author

DDtKey commented Jun 30, 2020

@dotenv-linter/maintainers glad to hear any comments and discuss this

install.sh Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
install.sh Outdated Show resolved Hide resolved
install.sh Outdated Show resolved Hide resolved
install.sh Outdated Show resolved Hide resolved
install.sh Outdated Show resolved Hide resolved
install.sh Outdated Show resolved Hide resolved
install.sh Outdated Show resolved Hide resolved
install.sh Outdated Show resolved Hide resolved
@mgrachev
Copy link
Member

@DDtKey I've left some comments. Please, look at them.

Also, please look at this example of installing via a script: https://github.com/reviewdog/reviewdog#installation.
I like that API. Can we have something like that? 🙂

@mgrachev
Copy link
Member

Also, it would be nice if we could test this script via GitHub Actions on Linux, Mac and Windows.
What do you think about it?

@DDtKey
Copy link
Member Author

DDtKey commented Jul 2, 2020

Also, it would be nice if we could test this script via GitHub Actions on Linux, Mac and Windows.
What do you think about it?

Good idea, but until release 2.1.0 we cannot run a script test for Windows, because there are no published versions.
He will fall.
We can certainly expect this now, and after the release update test behavior 🤔

@mgrachev
Copy link
Member

mgrachev commented Jul 2, 2020

Good idea, but until release 2.1.0 we cannot run a script test for Windows, because there are no published versions.
He will fall.
We can certainly expect this now, and after the release update test behavior 🤔

Agree. In the first iteration we can add tests only for Mac and Linux.

@DDtKey
Copy link
Member Author

DDtKey commented Jul 3, 2020

Also, it would be nice if we could test this script via GitHub Actions on Linux, Mac and Windows.
What do you think about it?

I made the changes we talked about, also added CI tests

@DDtKey DDtKey requested a review from mgrachev July 3, 2020 19:21
.github/workflows/ci.yml Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
docs/install.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
docs/install.md Outdated Show resolved Hide resolved
install.sh Outdated Show resolved Hide resolved
install.sh Outdated Show resolved Hide resolved
install.sh Show resolved Hide resolved
@DDtKey DDtKey requested a review from mgrachev July 4, 2020 10:58
mgrachev
mgrachev previously approved these changes Jul 4, 2020
@mgrachev mgrachev mentioned this pull request Jul 4, 2020
5 tasks
@DDtKey DDtKey added this to the v2.1.0 milestone Jul 6, 2020
@mgrachev
Copy link
Member

mgrachev commented Jul 7, 2020

@mstruebing What do you think about it?

# Conflicts:
#	CHANGELOG.md
@codecov-commenter
Copy link

Codecov Report

Merging #220 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##           master     #220   +/-   ##
=======================================
  Coverage   97.10%   97.10%           
=======================================
  Files          16       16           
  Lines        1485     1485           
=======================================
  Hits         1442     1442           
  Misses         43       43           

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 34ffdf7...20e9ca0. Read the comment docs.

@DDtKey
Copy link
Member Author

DDtKey commented Jul 8, 2020

I just resolved the conflict in CHANGELOG.md (merge master to current branch).

But faced with an unpleasant feature, when we use api github, it has limitations on the number of calls.

We need this to get the "latest" version.
I think this is not a problem in general, but CI starts quite often and this time it ran into a limit, which could happen again.

I see three possible solutions:

  1. In CI tests use a specific version to test the script (but we do not test to get the latest version unfortunately)
  2. As it was before: do not display the latest version number (i.e., use a static link to access the github, bypassing the api).
  3. Modify the script, for example, in case of an error in obtaining the version in api, download the latest version directly, bypassing the api

What do you think?
@dotenv-linter/core

install.sh Outdated Show resolved Hide resolved
@mstruebing
Copy link
Member

mstruebing commented Jul 8, 2020

  1. In CI tests use a specific version to test the script (but we do not test to get the latest version unfortunately)

In tests we could use https://github.com/dotenv-linter/dotenv-linter/releases/latest/download/dotenv-linter-os-arch.gz to always have the newest version

Why do we need to print the version number on install anyway? Wouldn't it be enough to say after installation finishes we present the user the version (by using dotenv-linter --version)?

@DDtKey
Copy link
Member Author

DDtKey commented Jul 8, 2020

  1. In CI tests use a specific version to test the script (but we do not test to get the latest version unfortunately)

In tests we could use https://github.com/dotenv-linter/dotenv-linter/releases/latest/download/dotenv-linter-os-arch.gz to always have the newest version

Why do we need to print the version number on install anyway? Wouldn't it be enough to say after installation finishes we present the user the version (by using dotenv-linter --version)?

This approach was used before discussing the print of the installed version

But in fact, I agree, this option will solve the problems of limiting api github and reduce the number of calls to curl / wget 🤔
What do you think? @mgrachev

@mgrachev
Copy link
Member

mgrachev commented Jul 8, 2020

Why do we need to print the version number on install anyway? Wouldn't it be enough to say after installation finishes we present the user the version (by using dotenv-linter --version)?

I like this idea 👍

@mstruebing
Copy link
Member

This approach was used before discussing the print of the installed version

Sorry, I didn't followed the conversation :)

@DDtKey
Copy link
Member Author

DDtKey commented Jul 8, 2020

@dotenv-linter/core thanks for feedback 👏
I returned using the latest version static URL to minimize API calls. User can always use dotenv-linter -v

install.sh Outdated Show resolved Hide resolved
@mgrachev
Copy link
Member

mgrachev commented Jul 8, 2020

I returned using the latest version static URL to minimize API calls. User can always use dotenv-linter -v

I thought that @mstruebing suggested getting the version of dotenv-linter using the dotenv-linter -v command and printing it after installation is completed. Or am I misunderstood?

@DDtKey
Copy link
Member Author

DDtKey commented Jul 8, 2020

I returned using the latest version static URL to minimize API calls. User can always use dotenv-linter -v

I thought that @mstruebing suggested getting the version of dotenv-linter using the dotenv-linter -v command and printing it after installation is completed. Or am I misunderstood?

This is my misunderstanding, I apologize, it option really impresses me. Thank you 👍

@DDtKey DDtKey requested a review from mgrachev July 8, 2020 14:44
@DDtKey DDtKey merged commit 935aa01 into dotenv-linter:master Jul 8, 2020
@DDtKey DDtKey mentioned this pull request Jul 8, 2020
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

Provide more short way to install dotenv-linter
4 participants