Permalink
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also or
learn more about diff comparisons.
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
Learn more about diff comparisons here.
...
- 17 commits
- 23 files changed
- 5 contributors
Commits on May 17, 2022
Commits on Dec 19, 2022
-
ci: Use Go 1.19 and update GH actions (#58)
This updates sally to build and test against Go 1.19. Additionally, this upgrades the GitHub Action versions for checkout and setup-go. One of the features in setup-go v3 is that caching is built-in and opted-into with `cache: true`. Non-CI changes: gofmt, drop ioutil
-
sally is a binary, not a library so it's okay to keep it on the latest dependencies. This sets up dependabot updates for Go modules used by sally.
-
Delete unused Docker infrastructure (#60)
This was all added back when these tests were running on Travis CI and attempted to create an isolated build of sally. This is all no longer necessary because GitHub Actions and Go modules provide enough isolation.
-
README: Document configuration further (#61)
Adds more details on how to configure sally and what the required and optional fields are. Also updates the installation instructions since you can't `go get` the binary anymore.
-
This simplifies the Makefile significantly, borrowing patterns we've used in other projects. Namely: - Set GOBIN to a bin subdirectory so that we can `go install` dependencies into it. - Use a shared TEST_FLAGS for `make test` and `make cover`. Without this, we're not running with data race detection in CI. - Build lint step out of separate golint and staticcheck steps. In the future, a gofmt step may also be added. - Move tools dependencies into an unpublished subpackage. Note: I didn't mess with the 'clean' and 'run' targets at the bottom of the file even though they're not necessary to avoid a merge conflict with #60.
-
Since upgrading to Go 1.19 we are seeing linter error due to usage of the deprecated io/ioutil package. This removes the usage of io/ioutil package.
Commits on Dec 21, 2022
-
Bump github.com/stretchr/testify from 1.2.2 to 1.8.1 (#63)
Bumps [github.com/stretchr/testify](https://github.com/stretchr/testify) from 1.2.2 to 1.8.1. - [Release notes](https://github.com/stretchr/testify/releases) - [Commits](stretchr/testify@v1.2.2...v1.8.1) --- updated-dependencies: - dependency-name: github.com/stretchr/testify dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Commits on Jan 23, 2023
-
config: Don't require packages to be alphabetical (#66)
The configuration parser requries that entries in the 'packages' section are in alphabetical order. It will fail parsing if that's not the case, even if the configuration is otherwise valid. This seems like an unnecessary artificial limitation. Enforcing such a convention should be the user's choice. This change deletes this limitation.
-
template: Use a more fluid layout (#67)
Instead of using a table, take advantage of the grid layout. We still print a table of sorts, but it's more fluid in appearance based on width of the screen. On narrower screens, we'll show a listing where each item has a description label next to it rather than at the top.
-
Add support for package descriptions (#68)
* template: Use a more fluid layout Instead of using a table, take advantage of the grid layout. We still print a table of sorts, but it's more fluid in appearance based on width of the screen. On narrower screens, we'll show a listing where each item has a description label next to it rather than at the top. * Add support for package descrpitions Packages may now optionally specify a description. If specified, this is printed below the package information, indented one column to make it stand out. Co-authored-by: Sung Yoon Whang <sungyoonwhang@gmail.com>
-
This dependency is used to format and compare HTML. An additional dependency isn't needed; we can use the existing (previously transitive) x/net package to reformat and compare the HTML.
-
Drop httprouter dependency (#71)
This drops the third-party HTTP router dependency. This dependency wasn't strictly necessary since our routing needs are quite basic: - `/$name` and `/$name/*` for all registered packages - `/` for root This is easily accomplished with `http.ServeMux`: - register `/$name` and `/$name/`. The latter will receive all subpackage requests. - register `/` and reject anything that isn't for exactly `/`.
-
* config: Don't require packages to be alphabetical The configuration parser requries that entries in the 'packages' section are in alphabetical order. It will fail parsing if that's not the case, even if the configuration is otherwise valid. This seems like an unnecessary artificial limitation. Enforcing such a convention should be the user's choice. This change deletes this limitation. * Upgrade to yaml.v3 * template: Use a more fluid layout (#67) Instead of using a table, take advantage of the grid layout. We still print a table of sorts, but it's more fluid in appearance based on width of the screen. On narrower screens, we'll show a listing where each item has a description label next to it rather than at the top. * Add support for package descriptions (#68) * template: Use a more fluid layout Instead of using a table, take advantage of the grid layout. We still print a table of sorts, but it's more fluid in appearance based on width of the screen. On narrower screens, we'll show a listing where each item has a description label next to it rather than at the top. * Add support for package descrpitions Packages may now optionally specify a description. If specified, this is printed below the package information, indented one column to make it stand out. Co-authored-by: Sung Yoon Whang <sungyoonwhang@gmail.com> Co-authored-by: Sung Yoon Whang <sungyoonwhang@gmail.com>
-
Adds a Dockerfile that builds sally using a phased Docker build. The first phase builds sally, and the second phase publishes a scratch image with just sally. If Uber publishes this to a container registry, a user can use it like so: % vim sally.yaml # create a sally yaml % cat > Dockerfile FROM sally:latest COPY sally.yaml /sally.yaml % docker build . Even without publishing, this provides an example of how to build sally for deployment. Testing: I verified the instructions above locally by tagging locally with: % docker build -t sally:latest I'm also using a variation of this Dockerfile in production right now for my own hosted instance of sally. -
-
Fix typo on release notes (#74)
Release notes for v1.3.0 had an incorrect link for changes included in v1.3.0; fixing this before we actually tag a release with this.
Loading
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:
git diff v1.2.0...v1.3.0