IMO we need some mechanism to show that the PR we merge should not create a release.

For example, a refactor PR, which should be tested as any other PR, but should not be released cause it provides no value for user.

... this could be interesting !

Add some basic README.md with utility description and a couple of examples

local package should be split intro a Docker daemon interaction part and tag operations part, and refactored. Eventually.

Something like --filter /^v.*/

• Maybe applicable multiple times. Connect with and or or (?)
• Maybe allowing to apply specified filters on selected repos only.

Need to complement and secure this: #60

@ivanilves could you stop making us look into travis.yml in order to get what we need to build the project?

Let's wrap all the cryptic hipster golang stuff with an old school Makefile:

• https://www.gnu.org/software/make/manual/make.html
• https://www.cs.umd.edu/class/fall2002/cmsc214/Tutorial/makefile.html

WDYT?

We need integration testing for lstags.

Cases like:

• Working against public registry
• Working against private registry
• Using different types of authentication
• ...

A pull (-p) dry run would show which images would be pulled.
A push (-P) dry run would show which images would a) be pulled and b) when the -r (external repo flag is given which images would be pushed to it.

This would allow for users to see issues like missing tags in a "plan" phase before running the actual pull/pull and push.

If this is wanted, depending on my time in the next weeks, I would be up to create a PR with this logic implemented.

Artifactory etc

Pull ones matched by #51

Maybe it's useless, but since we got Docker TCP support now it's a sin not to try! 😉

do we need to support loading config files from remote sources

http://user:[email protected]/file.yaml

???

GIF

We need to vendor dependencies inside the repo.

Integration suite broken after fddf058

Maybe we need to provide Kubernetes chart, some cron job to sync local docker images with registry?

... but they should 😉

... no so beautiful for now ...

Hi, It's a very useful tool. However I found a mismatch problem when our private registry is hosted on a port e.g. 5000. An example as below.

$ docker images
my.registry.com:5000/my_image                 my_tag          abfaa2fbade0        10 months ago       97MB

$ lstags my.registry.com:5000/my_image
<STATE>      <DIGEST>                                      <(local) ID>    <Created At>              <TAG>
LOCAL-ONLY   sha256:85b750cd33aa29ffce453f63984f4f6c9      abfaa2fbade0    2016-11-30T03:37:55-08:00 my.registry.com:5000/my_image:5000/my_image
ABSENT       sha256:85b750cd33aa29ffce453f63984f4f6c9      n/a             2016-11-30T03:37:55-08:00 my.registry.com:5000/my_image:my_tag

It seems the colon before the port number caused the wrong parsing result somewhere.

Thanks!

Extract registry authentication information from local Docker system.

One wise man said:

If docker pull can pull w/o reentering the password, why lstags can not execute like this?

Do we need this?

fetchRepoDetails is a total shit:

• ugly & messy
• slow

So:

• Make it better, re-compose the shitty-bloody-mess
• Make in concurrent

Currently we have no tests, which makes our code a ⏳ 💣

This issue #56 is probably solved by this PR #58

But what about us having integration test for local insecure/unauthenticated registry to make this feature more sustainable?

• #53 - match this!
• [Re]Push pulled images to a remote Docker registry

We need to be able to list multiple images. Like:

lstags alpine nginx containers.company.io

Unable to compare local and remote digests, cause they are always different.

More research required on this topic, as long as w/o solving this issue, the whole lstags idea is useless.

We can not rely on manual Docker API version specification!

We need Docker API version detector inside our application.

We have main.go tested but what about packages?

Could we also have some testing for packages?

We are not using concurrency mechanisms provided by Golang.

We are executing lots of HTTP requests sequentially, which is 🐢

I think the idea from @solidnerd PR #92 should be implemented.

We need automatic releases with our CI.

This means on every merged PR, we will need to:

• Bump release tag
• Build binaries for Linux and MacOSX
• Upload binaries to Dropbox or whatever

TODOs collected from #101

This is a development of #93

• Add client tests for unix socket
• Add client tests for tcp socket
• Add e2e support with docker-machine

cc @solidnerd

To become a better utility and also to become a package/library we need to separate core logic into a api package, so the main will become really bare and easy to understand. Also other people could include api as a Golang package [not just using CLI] with this.

Todo

• Provide API PoC #112
• Provide reliable integration tests for API #119
• Refactor API to get rid of PoC state #117
• Provide versioning of API (so developers may develop safely) #114
• Provide basic API documentation
• Build a PoC application using v1 lstags API
• Reach out to the new potential stakeholders

Just trying to get things up and running–

$ lstags --version
VERSION: v30-d15b77b
$ lstags alpine~/^3\\./
panic: runtime error: index out of range

goroutine 1 [running]:
github.com/ivanilves/lstags/docker/config.Load(0x1360289, 0x15, 0x0, 0x0, 0x0)
	/home/travis/gopath/src/github.com/ivanilves/lstags/docker/config/config.go:79 +0x4fe
main.main()
	/home/travis/gopath/src/github.com/ivanilves/lstags/main.go:98 +0x8d

Enforce our blackbox integration testing with a whitebox end2end job which will:

• start local registry
• pull image from public registry
• push it to local registry
• verify it was pulled/pushed correctly

We may also consider 2 tests one pull and one for pull/push.

We have reached the state when we need to:

• stop adding new functionality for a while.
• work more on automated testing, code quality and various fixes.
• add performance, benefit more of concurrency Golang gives us [almost] for free.

TODO

• Add black-box shell tests for "image pull" functionality.
• Fix lame ("double"?) help messages.
• Make registry and operations event more concurrent.
• Fix authenticated pull.

GIF

Now we have more tests and every CI run is around 5-7min.

We need to take it back to ~2-3min so development will be joyful again! 🚀

Options include:

• Parallelize regular & Docker build
• Run less tests for the PR, more for master merges
• Speed-up existing tests
• Remove some existing tests

... so no zone info will be needed, more compact output FTW!

Some simple Travis thing would be enough 😉

... to balance between having good speed and making DoS of Docker registry. ;)

Doing it "hard way" like we do it now is stable, but stupid.

Repo became huge: 57mb currently 😱

If we fear remote repo deletion, we should fork all remote repos and point dependencies to our forks.

we need to support configuration loading from yaml file as it is more scm/git friendly

Do we need it?

• Only for date?
• Really-really custom?