Skip to content
This repository has been archived by the owner on Feb 25, 2020. It is now read-only.

Allow per-project configuration of allowed repo-release diffs #20

Open
abesto opened this issue Apr 26, 2019 · 6 comments
Open

Allow per-project configuration of allowed repo-release diffs #20

abesto opened this issue Apr 26, 2019 · 6 comments

Comments

@abesto
Copy link
Contributor

abesto commented Apr 26, 2019

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.

@codefromthecrypt
Copy link

codefromthecrypt commented Apr 26, 2019 via email

@abesto
Copy link
Contributor Author

abesto commented Apr 30, 2019

When done, let's raise the level of the repo-archive comparison to FAIL maybe?

abesto added a commit that referenced this issue Apr 30, 2019
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
@codefromthecrypt
Copy link

codefromthecrypt commented May 1, 2019 via email

abesto added a commit that referenced this issue May 1, 2019
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
@basvanbeek
Copy link

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.

@abesto
Copy link
Contributor Author

abesto commented May 1, 2019

Sure, definitely let's not mark it as FAIL until we actually understand and trust it. Other than that, whether it's WARN or NOTE, I don't mind very much. Are you also suggesting NOTE in preference to WARN, or just non-FAIL?

abesto added a commit that referenced this issue May 18, 2019
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
```
@abesto
Copy link
Contributor Author

abesto commented May 18, 2019

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants