Detect non-inclusive language in your source code.

woke logo

Detect non-inclusive language in your source code.

I stay woke - Erykah Badu



GitHub release (latest SemVer) GitHub All Releases Build MIT License Go Report Card codecov

PkgGoDev pre-commit GitHub go.mod Go version FOSSA Status Mentioned in Awesome Go


Creating an inclusive work environment is imperative to a healthy, supportive, and productive culture, and an environment where everyone feels welcome and included.

woke is a text file analysis tool that finds places within your source code that contain non-inclusive language and suggests replacing them with more inclusive alternatives.

Companies like GitHub, Twitter, and Apple are actively supporting a move to inclusive language.

woke.gif

Why is this named woke?

When I started writing woke in August 2020, my goal was to build a tool that would shed light on non-inclusive language in source code and that would enable a long-term commitment to using inclusive language.

woke is a reference to an awareness of social and political issues, especially racial prejudice and discrimination, and has a historic use within the African-American community. This tool aims to push this kind of awareness even further into the software development community.

I named this project woke because I saw it as a tool to awaken our code to non-inclusive language.

You can read more about the origins and history of the word on Wikipedia.

Install woke

Documentation

Documentation is hosted at https://docs.getwoke.tech.

Contributing

Please read CONTRIBUTING.md for details on our code of conduct, and the process for submitting pull requests to us.

GitHub contributors

Authors

See also the list of contributors who have participated in this project.

License

This application is licensed under the MIT License, you may obtain a copy of it here.

FOSSA Status

Owner
Comments
  • Installer script doesn't understand `linux/arm64`

    Installer script doesn't understand `linux/arm64`

    Thank you for creating the issue!

    • [X] Yes, I've searched similar issues on GitHub and didn't find any.
    • [ ] Yes, I've included all information below (version, config, etc).

    Inside an Alpine Linux Docker container running on my M1-based Mac, I am trying to install Woke. From my Dockerfile:

    RUN curl -sSLf https://git.io/getwoke | bash -s -- -b /usr/local/bin
    

    I receive the following error during docker build:

    get-woke/woke crit platform linux/arm64 is not supported. Make sure this script is up-to-date and file request at https://github.com/get-woke/woke/issues/new

    Looks like the installer script doesn't understand linux/arm64, even though you publish the packages in the releases.

  • Support Windows colors

    Support Windows colors

    Please check if the PR fulfills these requirements

    • [x] The commit message follows our guidelines
    • [ ] Tests for the changes have been added (for bug fixes / features)
    • [ ] Docs have been added / updated (for bug fixes / features)

    What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

    Support Windows colors

    What is the current behavior? (You can also link to an open issue here)

    image

    What is the new behavior (if this is a feature change)?

    image

    Does this PR introduce a breaking change? (What changes might users need to make due to this PR?)

    No

    Other information:

    No

  • woke check fails for git submodules

    woke check fails for git submodules

    Hi, it seems that woke version 0.18.1 has a bug handling git submodules. I think the problem is with the fix to this woke issue (https://github.com/get-woke/woke/issues/102), causing woke to look for the .git/info/exclude directory, and throwing an error if it doesn't find it (instead of just moving on):

    14-Apr [21:24:03.052]  Error: open .../.git/info/exclude: not a directory
    

    The problem is that git submodules don't have a .git/ directory, only a .git file.

    • [ x ] Yes, I've searched similar issues on GitHub and didn't find any.
    • [ x ] Yes, I've included all information below (version, config, etc).

    Please include the following information:

    Version of woke
    $ woke --version
    woke version 0.18.1
    
    Config file

    Default

    Go environment
    $ go version && go env
    # paste output here
    
    Verbose output of running
    $ woke --debug
    2022-04-19T09:47:28+02:00 DBG woke version 0.18.1 built from 939e604 on 2022-03-19T15:45:29Z
    2022-04-19T09:47:28+02:00 DBG no config file loaded, using only default rules
    2022-04-19T09:47:28+02:00 DBG default rules rules=["whitelist","blacklist","master-slave","slave","grandfathered","man-hours","sanity","dummy","guys","whitebox","blackbox"]
    2022-04-19T09:47:28+02:00 DBG all enabled rules rules=["whitelist","blacklist","master-slave","slave","grandfathered","man-hours","sanity","dummy","guys","whitebox","blackbox"]
    2022-04-19T09:47:28+02:00 DBG finished compiling ignores durationMS=148.256037
    2022-04-19T09:47:28+02:00 DBG woke completed durationMS=148.479722
    Error: open /Users/.../.git/info/exclude: not a directory
    Usage:
      woke [globs ...] [flags]
    
    Flags:
      -c, --config string           Config file (default is .woke.yaml in current directory, or $HOME)
          --debug                   Enable debug logging
          --disable-default-rules   Disable the default ruleset
          --exit-1-on-failure       Exit with exit code 1 on failures
      -h, --help                    help for woke
          --no-ignore               Ignored files in .gitignore, .ignore, .wokeignore, .git/info/exclude, and inline ignores are processed
      -o, --output string           Output type [text,simple,github-actions,json,sonarqube] (default "text")
          --stdin                   Read from stdin
      -v, --version                 version for woke
    
    2022-04-19T09:47:28+02:00 FTL  error="open /Users/.../.git/info/exclude: not a directory"
    
    
  • add woke ignore traversal

    add woke ignore traversal

    Please check if the PR fulfills these requirements

    • [x] The commit message follows our guidelines
    • [x] Tests for the changes have been added (for bug fixes / features)
    • [x] Docs have been added / updated (for bug fixes / features)

    What kind of change does this PR introduce? (Bug fix, feature, docs update, ...) Feature

    What is the current behavior? (You can also link to an open issue here) Woke currently only looks at .gitignore and .wokeignore files in the current directory.

    What is the new behavior (if this is a feature change)? Woke will now traverse a repo and build a priority ranked list of ignore rules in exactly the same way that git does for .gitignore files at different directory levels. The tool will look for the root git directory (where the .git folder is) and use that for the root. If no root git directory is found then woke will just run with the current directory as root (still traversing children folders).

    Does this PR introduce a breaking change? (What changes might users need to make due to this PR?) No

    Other information: Addresses #98

  • --stdin not working?

    --stdin not working?

    I tried the README example for running woke on stdin and it didn't work:

    echo "This has whitelist from stdin" | woke --stdin
    No violations found. Stay woke ✊
    

    I just tried installing with:

    curl -sSfL https://git.io/getwoke | \
      bash -s -- -b /usr/local/bin
    

    My version:

    woke --version
    # woke version 0.9.0
    

    The same issue if I try the go get route as well.

  • Use word boundaries (\b) or ChangeInCase to reduce false positives

    Use word boundaries (\b) or ChangeInCase to reduce false positives

    I have a "redline" rule in a woke config.

    • https://www.washingtonpost.com/news/wonk/wp/2018/03/28/redlining-was-banned-50-years-ago-its-still-hurting-minorities-today/
    • https://en.wikipedia.org/wiki/Redlining
    • https://www.investopedia.com/terms/r/redlining.asp

    However, in some code, I found this example that I don't believe should be causing a violation (IMO):

    const measuredLineHeight = getComputedStyle(el).lineHeight;
    

    Which contains the substring, but I think might have enough signal to not marked.

    • [x] Yes, I've searched similar issues on GitHub and didn't find any.

    Kinda, https://github.com/get-woke/woke/issues/58 is similar-ish (except that in my case I do want the code to be checked).

    • [x] Yes, I've included all information below (version, config, etc).

    Please include the following information:

    Version of woke
    $ woke --version
    woke version 0.9.0
    
    Config file
    $ cat .woke.yml
    rules:
      - name: redline
        terms:
          - redline
        alternatives:
          - annotate
    
    Go environment
    $ go version && go env
    go: command not found
    
    Verbose output of running
    $ woke --debug
    2021-05-25T10:18:40-07:00 DBG woke version 0.9.0 built from 4e1a9a0 on 2021-05-22T15:23:11Z
    2021-05-25T10:18:40-07:00 DBG loaded config file config=/path/to/woke-repro/.woke.yml
    2021-05-25T10:18:40-07:00 DBG rules enabled rules=["redline","whitelist","blacklist","master-slave","slave","grandfathered","man-hours","sanity","dummy","guys","whitebox","blackbox"]
    2021-05-25T10:18:40-07:00 DBG skipping ignorefile error="open .gitignore: no such file or directory" file=.gitignore
    2021-05-25T10:18:40-07:00 DBG skipping ignorefile error="open .wokeignore: no such file or directory" file=.wokeignore
    2021-05-25T10:18:40-07:00 DBG finished compiling ignores durationMS=0.127734
    2021-05-25T10:18:40-07:00 DBG created new printer printer=text
    2021-05-25T10:18:40-07:00 DBG process files path=. type=parallel
    2021-05-25T10:18:40-07:00 DBG skipping file=.woke.yml reason="ignored file"
    2021-05-25T10:18:40-07:00 DBG skipping content file=. reason="file is a directory"
    2021-05-25T10:18:40-07:00 DBG finished processing violations durationMS=0.191194 file=.
    2021-05-25T10:18:40-07:00 DBG finished processing violations durationMS=0.126851 file=test.js
    test.js:1:11-18: `redLine` may be insensitive, use `annotate` instead (error)
    const measuredLineHeight = getComputedStyle(el).lineHeight;
               ^
    2021-05-25T10:18:40-07:00 DBG woke completed durationMS=1.012913
    
  • Woke v0.18.0 fails to install from source due to replace directive

    Woke v0.18.0 fails to install from source due to replace directive

    Hello! Recently we started running into issues installing woke. After some investigation it seems to be due to this recent change: https://github.com/get-woke/woke/pull/117.

    Currently we are installing woke by running:

    go install github.com/get-woke/woke@latest
    

    Unfortunately after the recent changes it now results in this error:

      go: downloading github.com/get-woke/woke v0.18.0
      go install github.com/get-woke/woke@latest: github.com/get-woke/[email protected]
      	The go.mod file for the module providing named packages contains one or
      	more replace directives. It must not contain directives that would cause
      	it to be interpreted differently than if it were the main module.
    

    Reading through the woke docs, the recommended way to install from source is to run:

    go get -u github.com/get-woke/woke
    

    However, the recommended command results in a warning:

    go get: installing executables with 'go get' in module mode is deprecated.
    	Use 'go install pkg@version' instead.
    	For more information, see https://golang.org/doc/go-get-install-deprecation
    	or run 'go help get' or 'go help install'.
    

    Reading through the document linked in the warning, it seems like this method will stop working in Go 1.18. The document recommends using go install instead. Unfortunately go install doesn't like replace directives. I found this thread in the Go issue tracker discussing it: https://github.com/golang/go/issues/44840. Please correct me if I have said anything that is incorrect or partially incorrect. This is my first time running into this issue with a tool.

    I didn't look into the context of why the replace directive was added to woke. I am not sure if it is easy to remove or if there is a better solution that achieves all of the desired goals.

    My current workaround is to install v0.17.0 instead of latest.

  • Investigate `filepath.WalkDir` to replace `fastwalk`

    Investigate `filepath.WalkDir` to replace `fastwalk`

    filepath.WalkDir was added in go 1.16 (https://tip.golang.org/doc/go1.16#path/filepath), which does not call os.Lstat on every visited file or directory, which filepath.Walk does.

    This is the reason I went with fastwalk (more details here: https://github.com/s12chung/fastwalk/wiki)

    Acceptance criteria

    • [ ] Replace fastwalk with filepath.WalkDir in https://github.com/get-woke/woke/blob/5b45f81dc8522c436f782e3093094a1c15da9bbd/pkg/walker/walker.go#L14-L24. The same behavior should be expected
    • [ ] Measure performance impact of filepath.WalkDir vs fastwalk (ie benchmark/pprof) and record results here
    • [ ] Determine if fastwalk should be replaced
  • woke panics if a wokeignore comment is at the start of a line.

    woke panics if a wokeignore comment is at the start of a line.

    Thank you for creating the issue!

    • [x] Yes, I've searched similar issues on GitHub and didn't find any.
    • [x] Yes, I've included all information below (version, config, etc).

    Toy example of the issue:

    [~/Documents/code/woke] nkrichevsky@nkrichevsky-mbp$ cat blah.txt
    /* wokeignore:rule=master-slave */ master-slave
    [~/Documents/code/woke] nkrichevsky@nkrichevsky-mbp$ ./woke blah.txt
    panic: runtime error: slice bounds out of range [:103] with length 47
    
    goroutine 34 [running]:
    github.com/get-woke/woke/pkg/result.FindResults(0xc00017b5e0, 0x7ffeefbff3af, 0x8, 0xc0000aa000, 0x2f, 0x1, 0x0, 0x0, 0x0)
        /Users/nkrichevsky/Documents/code/woke/pkg/result/lineresult.go:53 +0x445
    github.com/get-woke/woke/pkg/parser.(*Parser).generateFileFindings(0xc000198e10, 0xc000092000, 0x0, 0x0, 0x0)
        /Users/nkrichevsky/Documents/code/woke/pkg/parser/findings.go:73 +0x5a5
    github.com/get-woke/woke/pkg/parser.(*Parser).generateFileFindingsFromFilename(0xc000198e10, 0x7ffeefbff3af, 0x8, 0x0, 0x0, 0x0)
        /Users/nkrichevsky/Documents/code/woke/pkg/parser/findings.go:23 +0xcf
    github.com/get-woke/woke/pkg/parser.(*Parser).processFiles.func1(0xc0001bc820, 0xc000198e10, 0x7ffeefbff3af, 0x8)
        /Users/nkrichevsky/Documents/code/woke/pkg/parser/parser.go:91 +0x6b
    created by github.com/get-woke/woke/pkg/parser.(*Parser).processFiles
        /Users/nkrichevsky/Documents/code/woke/pkg/parser/parser.go:88 +0x9e
    

    I think this is due to the fact that unicode.ReplacementChar is actually a three byte symbol (see: https://play.golang.org/p/Jl1WrtoRDM0), so the index within the re function is at the wrong offset. (indeed, changing it from unicode.ReplacementChar to an underscore removes the panic, but I don't know if this is a suitable solution).

    Please include the following information:

    Version of woke
    $ go run main.go --version
    woke version main (it's v0.10.1)
    
    Config file

    Default

    Go environment
    $ go version && go env
    go version go1.16.5 darwin/amd64
    GO111MODULE=""
    GOARCH="amd64"
    GOBIN=""
    GOCACHE="/Users/nkrichevsky/Library/Caches/go-build"
    GOENV="/Users/nkrichevsky/Library/Application Support/go/env"
    GOEXE=""
    GOFLAGS=""
    GOHOSTARCH="amd64"
    GOHOSTOS="darwin"
    GOINSECURE=""
    GOMODCACHE="/Users/nkrichevsky/go/pkg/mod"
    GONOPROXY=""
    GONOSUMDB=""
    GOOS="darwin"
    GOPATH="/Users/nkrichevsky/go"
    GOPRIVATE=""
    GOPROXY="https://proxy.golang.org,direct"
    GOROOT="/usr/local/Cellar/go/1.16.5/libexec"
    GOSUMDB="sum.golang.org"
    GOTMPDIR=""
    GOTOOLDIR="/usr/local/Cellar/go/1.16.5/libexec/pkg/tool/darwin_amd64"
    GOVCS=""
    GOVERSION="go1.16.5"
    GCCGO="gccgo"
    AR="ar"
    CC="clang"
    CXX="clang++"
    CGO_ENABLED="1"
    GOMOD="/dev/null"
    CGO_CFLAGS="-g -O2"
    CGO_CPPFLAGS=""
    CGO_CXXFLAGS="-g -O2"
    CGO_FFLAGS="-g -O2"
    CGO_LDFLAGS="-g -O2"
    PKG_CONFIG="pkg-config"
    GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/gj/6g23qq697ddc5mx6ry8ypdy80000gp/T/go-build2259988605=/tmp/go-build -gno-record-gcc-switches -fno-common"
    
    Verbose output of running
    $ ./woke --debug blah.txt
    2021-07-21T13:22:59-04:00 DBG woke version main built from 000000 on today
    2021-07-21T13:22:59-04:00 DBG rules enabled rules=["whitelist","blacklist","master-slave","slave","grandfathered","man-hours","sanity","dummy","guys","whitebox","blackbox"]
    2021-07-21T13:22:59-04:00 DBG adding ignorefile file=.gitignore
    2021-07-21T13:22:59-04:00 DBG adding ignorefile file=.wokeignore
    2021-07-21T13:22:59-04:00 DBG adding ignorefile file=.git/info/exclude
    2021-07-21T13:22:59-04:00 DBG finished compiling ignores durationMS=0.760226
    2021-07-21T13:22:59-04:00 DBG created new printer printer=text
    2021-07-21T13:22:59-04:00 DBG process files path=blah.txt type=parallel
    2021-07-21T13:22:59-04:00 DBG ignoring via in-line file=blah.txt line=1 rule=master-slave
    2021-07-21T13:22:59-04:00 DBG finished processing findings durationMS=0.325451 file=blah.txt
    panic: runtime error: slice bounds out of range [:103] with length 47
    
    goroutine 34 [running]:
    github.com/get-woke/woke/pkg/result.FindResults(0xc0001295e0, 0x7ffeefbff3af, 0x8, 0xc000226000, 0x2f, 0x1, 0x0, 0x0, 0x0)
        /Users/nkrichevsky/Documents/code/woke/pkg/result/lineresult.go:53 +0x445
    github.com/get-woke/woke/pkg/parser.(*Parser).generateFileFindings(0xc0001451d0, 0xc00020e000, 0x0, 0x0, 0x0)
        /Users/nkrichevsky/Documents/code/woke/pkg/parser/findings.go:73 +0x5a5
    github.com/get-woke/woke/pkg/parser.(*Parser).generateFileFindingsFromFilename(0xc0001451d0, 0x7ffeefbff3af, 0x8, 0x0, 0x0, 0x0)
        /Users/nkrichevsky/Documents/code/woke/pkg/parser/findings.go:23 +0xcf
    github.com/get-woke/woke/pkg/parser.(*Parser).processFiles.func1(0xc000168c40, 0xc0001451d0, 0x7ffeefbff3af, 0x8)
        /Users/nkrichevsky/Documents/code/woke/pkg/parser/parser.go:91 +0x6b
    created by github.com/get-woke/woke/pkg/parser.(*Parser).processFiles
        /Users/nkrichevsky/Documents/code/woke/pkg/parser/parser.go:88 +0x9e
    
  • default rules set doesn't appear to be valid yaml

    default rules set doesn't appear to be valid yaml

    Hi, thank you for building this tool! I'm evaluating it for use on my team's project :)

    I've been testing out the configuration options, including writing my own rules yaml file. The default rules set (https://github.com/get-woke/woke/blob/main/pkg/rule/default.yaml) noted in the README (https://github.com/get-woke/woke#rules) seemed like a good starting point, since it has many of the same terms and suggested alternatives as my own team would like to use.

    However, when I pasted this default rules set into my local .woke.yaml, woke fails with a yaml parsing error - yaml: unmarshal errors:\n line 2: cannot unmarshal !!seq into config.Config. I was able to work around this by adding a top level rules: entry in the yaml, but this definitely confused me for a good 30 minutes or so :)

    • [x] Yes, I've searched similar issues on GitHub and didn't find any.
    • [x] Yes, I've included all information below (version, config, etc).

    Please include the following information:

    Woke v0.9.1
    $ woke --version
    # paste output here
    woke version 0.9.1
    
    Config file
    $ cat .woke.yml
    # paste output here
    
    # Most of these are based on https://twitter.com/TwitterEng/status/1278733303508418560
    - name: whitelist
      terms:
        - whitelist
        - white-list
        - whitelisted
        - white-listed
      alternatives:
        - allowlist
        - inclusion list
      severity: warning
      note: "The underlying assumption of the whitelist/blacklist metaphor is that white = good and black = bad. Because colors in and of themselves have no predetermined meaning, any meaning we assign to them is cultural: for example, the color red in many Southeast Asian countries is lucky, and is often associated with events like marriages, whereas the color white carries the same connotations in many European countries. In the case of whitelist/blacklist, the terms originate in the publishing industry – one dominated by the USA and England, two countries which participated in slavery and which grapple with their racist legacies to this day."
    
    - name: blacklist
      terms:
        - blacklist
        - black-list
        - blacklisted
        - black-listed
      alternatives:
        - denylist
        - blocklist
        - exclusion list
      severity: warning
      note: "The underlying assumption of the whitelist/blacklist metaphor is that white = good and black = bad. Because colors in and of themselves have no predetermined meaning, any meaning we assign to them is cultural: for example, the color red in many Southeast Asian countries is lucky, and is often associated with events like marriages, whereas the color white carries the same connotations in many European countries. In the case of whitelist/blacklist, the terms originate in the publishing industry – one dominated by the USA and England, two countries which participated in slavery and which grapple with their racist legacies to this day."
    
    - name: master-slave
      terms:
        - master-slave
        - master/slave
      alternatives:
        - leader/follower
        - primary/replica
        - primary/standby
    
    - name: slave
      terms:
        - slave
      alternatives:
        - follower
        - replica
        - standby
    
    - name: grandfathered
      terms:
        - grandfathered
      alternatives:
        - legacy status
    
    - name: man-hours
      terms:
        - man hours
        - man-hours
      alternatives:
        - person hours
        - engineer hours
    
    - name: sanity
      terms:
        - sanity
      alternatives:
        - confidence
        - quick check
        - coherence check
    
    - name: dummy
      terms:
        - dummy
      alternatives:
        - placeholder
        - sample
    
    - name: guys
      terms:
        - guys
      alternatives:
        - folks
        - people
        - you all
        - y'all
        - yinz
    
    - name: whitebox
      terms:
        - white-box
        - whitebox
        - white box
      alternatives:
        - open-box
    
    - name: blackbox
      terms:
        - black-box
        - blackbox
        - black box
      alternatives:
        - closed-box
    
    Go environment
    $ go version && go env
    # paste output here
    go not installed - running windows binaries from https://github.com/get-woke/woke/releases/tag/v0.9.1
    
    Verbose output of running
    $ woke --debug
    # paste output here
    2021-06-21T14:47:42-07:00 DBG woke version 0.9.1 built from 0dc3fe3 on 2021-06-20T17:59:32Z
    2021-06-21T14:47:42-07:00 DBG woke completed durationMS=0.6245
    Error: yaml: unmarshal errors:
      line 2: cannot unmarshal !!seq into config.Config
    Usage:
      woke [globs ...] [flags]
    
    Flags:
      -c, --config string       Config file (default is .woke.yaml in current directory, or $HOME)
          --debug               Enable debug logging
          --exit-1-on-failure   Exit with exit code 1 on failures
      -h, --help                help for woke
          --no-ignore           Ignored files in .gitignore/.wokeignore and inline ignores are processed
      -o, --output string       Output type [text,simple,github-actions,json] (default "text")
          --stdin               Read from stdin
      -v, --version             version for woke
    
    2021-06-21T14:47:42-07:00 FTL  error="yaml: unmarshal errors:\n  line 2: cannot unmarshal !!seq into config.Config"
    
  • Fix replacement suggestions for blacklist / whitelist

    Fix replacement suggestions for blacklist / whitelist

    It is apparent that this project has fallen under an inconsiderate paradigm in regards to the replacement of "blacklist" / "whitelist" terminology. Replacements such as "allowlist" are not viable unfortunately.

    This is not the only organization, of course, so no blame is on the developers. I am part of a group of people seeking to spread awareness on this :)

    For more information, see:

    Thank you in advance for your time.

  • build(deps): bump actions/cache from 3.0.5 to 3.2.2

    build(deps): bump actions/cache from 3.0.5 to 3.2.2

    Bumps actions/cache from 3.0.5 to 3.2.2.

    Release notes

    Sourced from actions/cache's releases.

    v3.2.2

    What's Changed

    New Contributors

    Full Changelog: https://github.com/actions/cache/compare/v3.2.1...v3.2.2

    v3.2.1

    What's Changed

    Full Changelog: https://github.com/actions/cache/compare/v3.2.0...v3.2.1

    v3.2.0

    What's Changed

    New Contributors

    ... (truncated)

    Changelog

    Sourced from actions/cache's changelog.

    3.0.5

    • Removed error handling by consuming actions/cache 3.0 toolkit, Now cache server error handling will be done by toolkit. (PR)

    3.0.6

    • Fixed #809 - zstd -d: no such file or directory error
    • Fixed #833 - cache doesn't work with github workspace directory

    3.0.7

    • Fixed #810 - download stuck issue. A new timeout is introduced in the download process to abort the download if it gets stuck and doesn't finish within an hour.

    3.0.8

    • Fix zstd not working for windows on gnu tar in issues #888 and #891.
    • Allowing users to provide a custom timeout as input for aborting download of a cache segment using an environment variable SEGMENT_DOWNLOAD_TIMEOUT_MINS. Default is 60 minutes.

    3.0.9

    • Enhanced the warning message for cache unavailablity in case of GHES.

    3.0.10

    • Fix a bug with sorting inputs.
    • Update definition for restore-keys in README.md

    3.0.11

    • Update toolkit version to 3.0.5 to include @actions/core@^1.10.0
    • Update @actions/cache to use updated saveState and setOutput functions from @actions/core@^1.10.0

    3.1.0-beta.1

    • Update @actions/cache on windows to use gnu tar and zstd by default and fallback to bsdtar and zstd if gnu tar is not available. (issue)

    3.1.0-beta.2

    • Added support for fallback to gzip to restore old caches on windows.

    3.1.0-beta.3

    • Bug fixes for bsdtar fallback if gnutar not available and gzip fallback if cache saved using old cache action on windows.

    3.2.0-beta.1

    • Added two new actions - restore and save for granular control on cache.

    3.2.0

    • Released the two new actions - restore and save for granular control on cache

    3.2.1

    • Update @actions/cache on windows to use gnu tar and zstd by default and fallback to bsdtar and zstd if gnu tar is not available. (issue)
    • Added support for fallback to gzip to restore old caches on windows.
    • Added logs for cache version in case of a cache miss.

    3.2.2

    • Reverted the changes made in 3.2.1 to use gnu tar and zstd by default on windows.
    Commits
    • 4723a57 Revert compression changes related to windows but keep version logging (#1049)
    • d1507cc Merge pull request #1042 from me-and/correct-readme-re-windows
    • 3337563 Merge branch 'main' into correct-readme-re-windows
    • 60c7666 save/README.md: Fix typo in example (#1040)
    • b053f2b Fix formatting error in restore/README.md (#1044)
    • 501277c README.md: remove outdated Windows cache tip link
    • c1a5de8 Upgrade codeql to v2 (#1023)
    • 9b0be58 Release compression related changes for windows (#1039)
    • c17f4bf GA for granular cache (#1035)
    • ac25611 docs: fix an invalid link in workarounds.md (#929)
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • Simplify dev container and fix pre-commit repo

    Simplify dev container and fix pre-commit repo

    Please check if the PR fulfills these requirements

    • [x] The commit message follows our guidelines
    • [ ] Tests for the changes have been added (for bug fixes / features)
    • [ ] Docs have been added / updated (for bug fixes / features) see docs/README.md

    What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

    Dev tools

    What is the current behavior? (You can also link to an open issue here)

    Coming back to this (on a fresh machine), the original dev container was no longer working for me and the pre-commit was failing to initialize on my end (both in dev containers and on my local machine). After installing the pre-commit and installing the Go dev tools, I was seeing a "Connection refused" error for the pre-commit-golang repo whenever I created a commit.

    I'm curious if others are able to reproduce these issues?

    What is the new behavior (if this is a feature change)?

    This PR replaces the old dev container with a new and simpler one, leveraging some of the recent updates from VS Code Dev Containers (i.e. dev container "features").

    This PR also resolves the pre-commit issues by replacing git://github.com/caitlinelfring/pre-commit-golang with https://github.com/caitlinelfring/pre-commit-golang. This got pre-commit working for me—I'm very curious if this still works for others!

    Does this PR introduce a breaking change? (What changes might users need to make due to this PR?)

    If contributors are still using the current dev container, they should be able to just "Rebuild Container" in VS Code to start using the updated one.

    If the pre-commit change also looks good and is accepted, contributors may need to run another pre-commit install to reflect the change.

    Other information:

    Please let me know your thoughts!

  • build(deps): bump goreleaser/goreleaser-action from 3 to 4

    build(deps): bump goreleaser/goreleaser-action from 3 to 4

    Bumps goreleaser/goreleaser-action from 3 to 4.

    Release notes

    Sourced from goreleaser/goreleaser-action's releases.

    v4.0.0

    What's Changed

    Full Changelog: https://github.com/goreleaser/goreleaser-action/compare/v3...v4.0.0

    v3.2.0

    What's Changed

    • chore: remove workaround for setOutput by @​crazy-max (#374)
    • chore(deps): bump @​actions/core from 1.9.1 to 1.10.0 (#372)
    • chore(deps): bump yargs from 17.5.1 to 17.6.0 (#373)

    Full Changelog: https://github.com/goreleaser/goreleaser-action/compare/v3.1.0...v3.2.0

    v3.1.0

    What's Changed

    • fix: dist resolution from config file by @​crazy-max (#369)
    • ci: fix workflow by @​crazy-max (#357)
    • docs: bump actions to latest major by @​crazy-max (#356)
    • chore(deps): bump crazy-max/ghaction-import-gpg from 4 to 5 (#360)
    • chore(deps): bump ghaction-import-gpg to v5 (#359)
    • chore(deps): bump @​actions/core from 1.6.0 to 1.8.2 (#358)
    • chore(deps): bump @​actions/core from 1.8.2 to 1.9.1 (#367)

    Full Changelog: https://github.com/goreleaser/goreleaser-action/compare/v3.0.0...v3.1.0

    Commits
    • 8f67e59 chore: regenerate
    • 78df308 chore(deps): bump minimatch from 3.0.4 to 3.1.2 (#383)
    • 66134d9 Merge remote-tracking branch 'origin/master' into flarco/master
    • 3c08cfd chore(deps): bump yargs from 17.6.0 to 17.6.2
    • 5dc579b docs: add example when using workdir along with upload-artifact (#366)
    • 3b7d1ba feat!: remove auto-snapshot on dirty tag (#382)
    • 23e0ed5 fix: do not override GORELEASER_CURRENT_TAG (#370)
    • 1315dab update build
    • b60ea88 improve install
    • 4d25ab4 Update goreleaser.ts
    • See full diff in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • Add an option

    Add an option "--count-only-error-for-failure"

    Description: --count-only-error-for-failure Count only error items, not warning and info, for failure

    We have a requirement for a word not to cause a failure when the word has a rule whose severity is warning or info.

    Note

    As long as the requirement is satisfied, we do not mind how it'd be implemented. So, if my proposal does not fit in the current design, please feel free to close this PR in favor of a better one. Thanks in advance!

    Please check if the PR fulfills these requirements

    • [x] The commit message follows our guidelines
    • [x] Tests for the changes have been added (for bug fixes / features)
    • [x] Docs have been added / updated (for bug fixes / features) see docs/README.md

    What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

    This PR adds an option --count-only-error-for-failure. When this option is given along with --exit-1-on-failure, even if a word whose rule specifies the warning level of severity (or info) is found, it does not exit as a failure.

    What is the current behavior? (You can also link to an open issue here)

    Regardless of the severity level, any finding makes woke exit with 1 if --exit-1-on-failure is specified.

    If you are interested in, this is the PR in which I ran into the issue. https://github.com/linux-system-roles/logging/pull/307#issuecomment-1343073890

    What is the new behavior (if this is a feature change)?

    If --count-only-error-for-failure is specified along with --exit-1-on-failure, findings whose rule has the warning or info level of the severity will not cause woke exit with 1.

    Does this PR introduce a breaking change? (What changes might users need to make due to this PR?)

    Unless --count-only-error-for-failure is specified, there are no behavioral changes.

  • build(deps): bump golangci/golangci-lint-action from 3.2.0 to 3.3.1

    build(deps): bump golangci/golangci-lint-action from 3.2.0 to 3.3.1

    Bumps golangci/golangci-lint-action from 3.2.0 to 3.3.1.

    Release notes

    Sourced from golangci/golangci-lint-action's releases.

    v3.3.1

    What's Changed

    Full Changelog: https://github.com/golangci/golangci-lint-action/compare/v3...v3.3.1

    v3.3.0

    What's Changed

    ... (truncated)

    Commits
    • 0ad9a09 build(deps-dev): bump @​typescript-eslint/parser from 5.41.0 to 5.42.0 (#599)
    • 235ea57 build(deps-dev): bump eslint from 8.26.0 to 8.27.0 (#598)
    • a6ed001 build(deps-dev): bump @​typescript-eslint/eslint-plugin from 5.41.0 to 5.42.0 ...
    • 3a7156a build(deps-dev): bump @​typescript-eslint/parser from 5.40.1 to 5.41.0 (#596)
    • 481f8ba build(deps): bump @​types/semver from 7.3.12 to 7.3.13 (#595)
    • 06edb37 build(deps-dev): bump @​typescript-eslint/eslint-plugin from 5.40.1 to 5.41.0 ...
    • c2f79a7 build(deps): bump @​actions/cache from 3.0.5 to 3.0.6 (#593)
    • d6eac69 build(deps-dev): bump @​typescript-eslint/eslint-plugin from 5.40.0 to 5.40.1 ...
    • 7268434 build(deps-dev): bump eslint from 8.25.0 to 8.26.0 (#591)
    • a926e2b build(deps-dev): bump @​typescript-eslint/parser from 5.40.0 to 5.40.1 (#590)
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • Added more keywords/rules based on the inclusivenaming.org

    Added more keywords/rules based on the inclusivenaming.org

    Please check if the PR fulfills these requirements

    • [x] The commit message follows our guidelines
    • [x] Tests for the changes have been added (for bug fixes / features)
    • [ ] Docs have been added / updated (for bug fixes / features) see docs/README.md

    What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

    • Added more rules based on inclusivenaming.org

    What is the current behavior? (You can also link to an open issue here)

    • Limited number of keywords

    What is the new behavior (if this is a feature change)?

    • More keywords to detect during the scan

    Does this PR introduce a breaking change? (What changes might users need to make due to this PR?)

    N/A

    Other information:

    N/A

The most opinionated Go source code linter for code audit.
The most opinionated Go source code linter for code audit.

go-critic Highly extensible Go source code linter providing checks currently missing from other linters. There is never too much static code analysis.

Jan 6, 2023
Retnilnil is a static analysis tool to detect `return nil, nil`

retnilnil retnilnil is a static analysis tool for Golang that detects return nil, nil in functions with (*T, error) as the return type. func f() (*T,

Jun 9, 2022
🐶 Automated code review tool integrated with any code analysis tools regardless of programming language
🐶 Automated code review tool integrated with any code analysis tools regardless of programming language

reviewdog - A code review dog who keeps your codebase healthy. reviewdog provides a way to post review comments to code hosting service, such as GitHu

Jan 2, 2023
🐶 Automated code review tool integrated with any code analysis tools regardless of programming language
🐶 Automated code review tool integrated with any code analysis tools regardless of programming language

reviewdog - A code review dog who keeps your codebase healthy. reviewdog provides a way to post review comments to code hosting service, such as GitHu

Jan 7, 2023
octocov is a tool for collecting code metrics (code coverage, code to test ratio and test execution time).

octocov is a tool for collecting code metrics (code coverage, code to test ratio and test execution time).

Jan 9, 2023
[mirror] This is a linter for Go source code.

Golint is a linter for Go source code. Installation Golint requires a supported release of Go. go get -u golang.org/x/lint/golint To find out where g

Dec 23, 2022
depth is tool to retrieve and visualize Go source code dependency trees.

depth is tool to retrieve and visualize Go source code dependency trees. Install Download the appropriate binary for your platform from the Rele

Dec 30, 2022
Print all source code for a given go package or module.

gosrcs gosrcs is a tool to print all the source code a given go package depends on. The original motivation of this tool is to integrate go builds int

Oct 25, 2021
A Golang tool that does static analysis, unit testing, code review and generate code quality report.
A Golang tool that does static analysis, unit testing, code review and generate code quality report.

goreporter A Golang tool that does static analysis, unit testing, code review and generate code quality report. This is a tool that concurrently runs

Jan 8, 2023
Sloc, Cloc and Code: scc is a very fast accurate code counter with complexity calculations and COCOMO estimates written in pure Go
Sloc, Cloc and Code: scc is a very fast accurate code counter with complexity calculations and COCOMO estimates written in pure Go

Sloc Cloc and Code (scc) A tool similar to cloc, sloccount and tokei. For counting physical the lines of code, blank lines, comment lines, and physica

Jan 4, 2023
Tool to populate your code with traceable and secure error codes

Essential part of any project, especially customer facing is proper and secure error handling. When error happens and customer reports it, it would be nice to know the context of the error and where it exactly occured.

Sep 28, 2022
🔒🌍 Security scanner for your Terraform code
🔒🌍 Security scanner for your Terraform code

????tfsec uses static analysis of your terraform templates to spot potential security issues.

Dec 30, 2022
Know when GC runs from inside your golang code

gcnotifier gcnotifier provides a way to receive notifications after every run of the garbage collector (GC). Knowing when GC runs is useful to instruc

Dec 26, 2022
Manage your repository's TODOs, tickets and checklists as config in your codebase.

tickgit ??️ tickgit is a tool to help you manage latent work in a codebase. Use the tickgit command to view pending tasks, progress reports, completio

Dec 30, 2022
Remove unnecessary type conversions from Go source

About The unconvert program analyzes Go packages to identify unnecessary type conversions; i.e., expressions T(x) where x already has type T. Install

Nov 28, 2022
a tool for code clone detection

dupl dupl is a tool written in Go for finding code clones. So far it can find clones only in the Go source files. The method uses suffix tree for seri

Dec 12, 2022
Run linters from Go code -

Lint - run linters from Go Lint makes it easy to run linters from Go code. This allows lint checks to be part of a regular go build + go test workflow

Sep 27, 2022
A reference for the Go community that covers the fundamentals of writing clean code and discusses concrete refactoring examples specific to Go.

A reference for the Go community that covers the fundamentals of writing clean code and discusses concrete refactoring examples specific to Go.

Jan 1, 2023
A static code analyzer for annotated TODO comments
A static code analyzer for annotated TODO comments

todocheck todocheck is a static code analyzer for annotated TODO comments. It let's you create actionable TODOs by annotating them with issues from an

Dec 7, 2022