-
Notifications
You must be signed in to change notification settings - Fork 1
Allow per-project configuration of allowed repo-release diffs #20
Comments
I love the idea of .asfignore indicating that this expression is
uninteresting for source validation
note that some ASF assemblies can have wildly different structure than the
source repo. however, I'll kindof park that for now :) I think this script
is about the fast-path, where there is congruence between the repo layout
and the distribution layout
|
When done, let's raise the level of the repo-archive comparison to FAIL maybe? |
Highlights: * Can now differentiate between "check failed" and "failed to run check" (latter gets printed as `[ERROR]`) * Individual checks can return various error levels, depending on the severity of problems they find. For example, the build-and-test check reports a `FAIL` level problem if it knows how to run tests, but they fail; on the other hand it reports a `NOTE` level problem if it doesn't know how to run tests. * Inline problem reporting is correctly colorized by level * Repo-Release archive comparison is downgraded to `WARN` until #20 is done
When done, let's raise the level of the repo-archive comparison to FAIL
maybe?
I still think we are way trigger happy on FAIL and really don't want to add
more FAIL things on things that aren't failures, especially until we get
through.
|
Highlights: * Can now differentiate between "check failed" and "failed to run check" (latter gets printed as `[ERROR]`) * Individual checks can return various error levels, depending on the severity of problems they find. For example, the build-and-test check reports a `FAIL` level problem if it knows how to run tests, but they fail; on the other hand it reports a `NOTE` level problem if it doesn't know how to run tests. * Inline problem reporting is correctly colorized by level * Repo-Release archive comparison is downgraded to `WARN` until #20 is done
I'd prefer NOTICE until we actually understand the behavior of the implementation. This is typically something that we'd want to try on our projects a few release iterations to assess if this needs to be strict, works for all involved repos and not drive blocking a snowflake project that doesn't fit but is not wrong either. |
Sure, definitely let's not mark it as |
With this change we read `.asfignore` from the Git checkout if it exists. For purposes of verifying that the git repo and the source archive match, files whose filenames match any filename specified in `.asfignore` is ignored. Note that there is currently no support for either specifying folders in `.asfignore`, or wildcards. It's a strict, filename-only match. Test without `.asfignore`: ``` $ python src/main.py --module zipkin-api --version 0.2.1 --gpg-key 50D90C2C \ --git-hash bc3cd4af4108f2ff7522d0c2782a6bb856bc05dd --repo release \ --zipname-template 'apache-{module}{dash_incubating}-{version}-source-release' \ --github-reponame-template '{module}.git' \ --github-org abesto ... [WARN] Git tree at provided revision matches source archive /tmp/tmpve7uk1ix/git/zipkin-api.git/javadoc is only in the git checkout /tmp/tmpve7uk1ix/git/zipkin-api.git/package-lock.json is only in the git checkout /tmp/tmpve7uk1ix/git/zipkin-api.git/package.json is only in the git checkout /tmp/tmpve7uk1ix/git/zipkin-api.git/pom.xml is only in the git checkout /tmp/tmpve7uk1ix/git/zipkin-api.git/src is only in the git checkout /tmp/tmpve7uk1ix/git/zipkin-api.git/validate.test.js is only in the git checkout The contents of the following files differ: zipkin2-api.yaml ``` Test with `.asfignore` committed into a fork: ``` $ python src/main.py --module zipkin-api --version 0.2.1 --gpg-key 50D90C2C \ --git-hash 3fa7beb2a2d6c7ec0f9e3f4965bbc3a19cc82a69 --repo release \ --zipname-template 'apache-{module}{dash_incubating}-{version}-source-release' \ --github-reponame-template '{module}.git' \ --github-org abesto ... [PASS] Git tree at provided revision matches source archive ``` `.asfignore` file used for the test: ``` javadoc package-lock.json package.json pom.xml validate.test.js zipkin2-api.yaml src ```
Note that even with #39 we won't be able to handle well situations where the layout of the source archive and the git repo are significantly different. Let's track that in a new issue whenever we run up against that problem. |
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.
The text was updated successfully, but these errors were encountered: