search

openzipkin-attic / apache-release-verification

Apache License 2.0
3 stars 1 forks source link

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

Open abesto opened 5 years ago

abesto commented 5 years ago

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 commented 5 years ago

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

abesto commented 5 years ago

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

codefromthecrypt commented 5 years ago

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.

basvanbeek commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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.