openzipkin-attic / apache-release-verification Goto Github PK

As noted on #22, we're getting to a point where we want to fine-tune the behavior of the checker tool. While every option should still be exposed through the CLI, we should start allowing configuration via a config file hosted in the source repo.

This is different from #20 in that this would need to be a structured configuration supporting various flags (think ~/.gitconfig vs .gitignore).

We still have a bootstrapping problem around the git repo: how do you read the config file if you don't know where the repo lives? Maybe the prudent thing to do would be to allow passing in the full path to the git repo to use. There's also the idea of storing per-project bootstrapping information somewhere centrally, and fetching them at runtime as needed.

zipkin-dependencies requires JDK 1.8 at the moment due to some spark integration tests. However, iirc all other projects can work with JDK 11, and brave requires it. There's a maven-enforcer-plugin which craps out with a message concerning the JDK in use vs what's required.

This part will fail if there's a JDK mismatch

Executing build-and-test for maven
>> Executing `mvn --quiet -N io.takari:maven:wrapper -Dmaven=3.6.0` in '/tmp/tmpa0w0xarb/unzipped/brave-5.6.4'

Twice I forgot to click close on the "convenience binary" staging repository which led to it being purged between vote and actual vote close. Recreating it is a pain. I wonder if we can script a check that the closed repo exists (even better have a maven plugin to close it! similar to our centralsync)

ex our scripts upload to here https://repository.apache.org/service/local/staging/deploy/maven2
currently you have to manually close the repo by logging on here https://repository.apache.org/

Originally posted by @drolando in #6

Roughly:

• make venv
• make lint (depends on venv)
• make run (depends on lint)

When we migrate the zipkin project into the Apache repo, it will be located at: https://github.com/apache/incubator-zipkin.git, the code as it exists now would look for it at: https://github.com/apache/incubator-zipkin-zipkin.git

Call it "optional / strict", "warning / fail", or whatever else that seems to make sense at the time. This allows introducing new checks in an "incubating" mode without generating much noise for "stable" users.

(More context in #22 (comment))

For example, we have an ongoing zipkin-dependencies release vote, which can be checked with the following command:

NO_CLEANUP=1 ./check.sh --module zipkin-dependencies --version 2.2.0 --gpg-key DA805D02 --git-hash 7d40f7be565116da3117f8ac24db3023a2183bd2 --github-reponame-template '{incubator_dash}{module}' --zipname-template 'apache-{module}{dash_incubating}-{version}-source-release'

This results in the "Executing build-and-test for maven" step failing (after quite a while on the step... not sure about why that is).

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:testCompile (default-testCompile) on project zipkin-dependencies-cassandra: Fatal error compiling: Error while executing the external compiler. Error while executing process. Cannot run program "javac" (in directory "/tmp/tmpcav5c0pz/unzipped/zipkin-dependencies-2.2.0/cassandra"): error=2, No such file or directory

The set JAVA_HOME points to a JRE installation, but we need a JDK installation to compile projects.

currently we fail like this. We should not require .github in the source dist

[FAIL] Git tree at provided revision matches source archive
/tmp/tmppa_5v1dw/git/incubator-zipkin/.github is only in the git checkout
See above for a full output of diff.

My verification failed in the script due to missing sha512sum. However, it passes when using normal shasum.

As suggested at #3 (comment).

Most reliable way would be figuring out a smart way of directly using git to do this. Second best is using something like https://github.com/mherrmann/gitignore_parser.

Pulling the Docker image initially (and upon certain updates to the tag) requires downloading quite large layers (hundreds of megabytes). Have we considered using the Alpine Linux variant for the base image to reduce the size of layers? How difficult would it be to switch to that, and what tradeoffs would it involve?

/cc @abesto

• It doesn't seem to output the names of matched files during runs
• This might not be valid? Consider zipkin/dependency-reduced-pom.xml in zipkin.

Disabling this check, along with .gitignore in the repo check for now.

@adriancole in #27:

probably it would help my brain a lot to classify what are actually ASF requirements from what are not. There's no requirement to have the files in the source dist match the repo. The first couple repos we've done matched so mentally we are anchored to this concept. Since we are testing things that are not requirements and not necessarily even valid. It would be cool to order the ones that are concrete at the top, then a line or something, then the extra checks we made up which may help, but are not actually requirements at the bottom.

I've just set up https://cloud.docker.com/repository/docker/abesto/openzipkin-contrib-apache-release-verification/. Next step of course is to $SUBJECT. I guess we should leave the option to build locally in check.sh if some ENV var is set.

Also, keep in mind the same README.md shows up on the Docker Hub page, so let's include instructions for running directly via docker.

According to the mail thread [VOTE] Release Apache Zipkin API (incubating) version 0.2.1, it's up to each project to decide what should and shouldn't be in the source repo (aside from licence and similar stuff). This means providing a sane default is good, but we should probably allow configuring this from the repository.

Since this check only runs once both the repo and the source archive are present, we can actually store this in the repo. Only question left is whether we can reuse some existing file. The obvious candidate is .gitignore, which we already check to make sure no .gitignore-d files show up in the source archive (or the git checkout, for that matter).

My first thought is an .asfignore file that contains paths which are OK to be omitted from the source archive. I'm not sure how to extend this to configure both directions. Maybe .asfignore-gitonly and .asfignore-releaseonly? Or a single file .asfignore but each line is prefixed with something? Maybe don't name it that to avoid hinting this is associated with some official ASF thing?

Open to suggestions.

In the future, we might want to add more tests with failure cases. If we have travis or jenkins or something running against an assortment of prior distributions, it could give confidence that new changes don't make other projects now invalid, or better yet that ones that should be invalid are now invalid.

This will likely be more important when there's more diversity than just maven projects, or projects outside zipkin.

I was thinking maybe a unit test that took parameters used in release votes and asserts that they still pass.

Useful for release managers to test the release before publishing. @adriancole in #22 (comment):

A future version of this be able to run against a local checkout to ensure
that someone doesn't accidentally waste time by missing one small detail. I
think that's a separate issue, but I find myself building the dist locally
nervously scanning the files so that I don't fail later.

Some binary files are actually totally fine, like images, for example. Also seems to mark .json files as binary for some reason. Downgrading to NOTE for now.

Need to enter username and password for anonymous cloning and the repo name is slightly odd.

Please see the logs below

Executing `git clone https://github.com/apache/incubator-zipkin-zipkin.git /tmp/tmpm3rcq1kv/git/incubator-zipkin-zipkin.git`
Cloning into '/tmp/tmpm3rcq1kv/git/incubator-zipkin-zipkin.git'...
Username for 'https://github.com': 

We were required to make addendums to the LICENSE file, which trips the verification tool like this. One possible way out is to look that the file starts with the stock LICENSE text as opposed to exactly equals.

[FAIL] LICENSE is Apache 2.0
Executing `diff /tmp/tmppa_5v1dw/expected_license /tmp/tmppa_5v1dw/unzipped/zipkin-2.14.0/LICENSE` exited with non-zero status code 1. See above for output. (Note that the command was run under `set -euo pipefail`)