Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: JENKINS-73837 - Adjusted DirScanner to allow empty directories in the TarArchiver #9836

Open
wants to merge 26 commits into
base: master
Choose a base branch
from

Conversation

DerSimeon
Copy link

See JENKINS-73837 .

Testing done

Proposed changelog entries

  • Update the DirScanner to include empty Directories in the TarArchiver

Proposed upgrade guidelines

N/A

Submitter checklist

Desired reviewers

@mention

Before the changes are marked as ready-for-merge:

Maintainer checklist

Copy link

welcome bot commented Oct 6, 2024

Yay, your first pull request towards Jenkins core was created successfully! Thank you so much!

A contributor will provide feedback soon. Meanwhile, you can join the chats and community forums to connect with other Jenkins users, developers, and maintainers.

@DerSimeon DerSimeon force-pushed the fix/JENKINS-73837-empty-dirs-in-tararchiver branch from dbfc3eb to fff2bae Compare October 6, 2024 23:03
@DerSimeon DerSimeon force-pushed the fix/JENKINS-73837-empty-dirs-in-tararchiver branch from fff2bae to 4f3652e Compare October 6, 2024 23:14
@DerSimeon
Copy link
Author

It seems that a lot of Tests fail when presented with empty directories.

@MarkEWaite
Copy link
Contributor

It seems that a lot of Tests fail when presented with empty directories.

Thanks for proposing the pull request. One of the expectations is that the automated tests must pass before a change is merged. We usually rely on the pull request submitter to make the necessary changes so that the existing automated tests are passing and are correctly expressing what is expected from the change in the pull request. Are you willing to make those changes?

@DerSimeon
Copy link
Author

Thanks for proposing the pull request. One of the expectations is that the automated tests must pass before a change is merged. We usually rely on the pull request submitter to make the necessary changes so that the existing automated tests are passing and are correctly expressing what is expected from the change in the pull request. Are you willing to make those changes?

Yes absolutely, I am already working on the VirtualFileTests.
However some support in the DirectoryBrowserSupportTest would be appreciated as I am having some difficulty understanding what's going on there.

@DerSimeon
Copy link
Author

@MarkEWaite could you take a look at my proposed fix?
While looking at the failing FilePathTest it appears as if it counts directories even if they aren't empty, causing FilePath#tar to return 4 (3 files + 1 dir).

@MarkEWaite
Copy link
Contributor

@MarkEWaite could you take a look at my proposed fix? While looking at the failing FilePathTest it appears as if it counts directories even if they aren't empty, causing FilePath#tar to return 4 (3 files + 1 dir).

I think that test failure is another indication that your change is working as desired. Before your change, the contents of that file were:

-rw-rw-r-- 0/0            2049 2024-10-07 16:59 dir/pom.xml
-rw-rw-r-- 0/0            2049 2024-10-07 16:59 pom.xml
-rw-rw-r-- 0/0            1537 2024-10-07 16:59 small.tar

After your change, an entry is written to the tar archive for the directory dir. After your change, the contents of that file are:

-rw-rw-r-- 0/0            2049 2024-10-07 16:57 dir/pom.xml
-rw-rw-r-- 0/0            2049 2024-10-07 16:57 pom.xml
-rw-rw-r-- 0/0            1537 2024-10-07 16:57 small.tar
drwxrwxr-x 0/0               0 2024-10-07 16:57 dir/

I think it is correct to change the 3 in that test to a 4.

@DerSimeon
Copy link
Author

@MarkEWaite hey! I have fixed all except one test. However with that last one I am going to need some support.

@github-actions github-actions bot added the unresolved-merge-conflict There is a merge conflict with the target branch. label Oct 13, 2024
Copy link
Contributor

Please take a moment and address the merge conflicts of your pull request. Thanks!

@github-actions github-actions bot removed the unresolved-merge-conflict There is a merge conflict with the target branch. label Oct 13, 2024
@DerSimeon
Copy link
Author

Also closes JENKINS-49296

@DerSimeon
Copy link
Author

/reviewer @jenkinsci/core-pr-reviewers

@timja
Copy link
Member

timja commented Oct 15, 2024

@timja could you check that failing windows test? to me it looks like a flaky test.

re-triggered

@basil basil added needs-ath-build Needs to run through the full acceptance-test-harness suite and removed ready-for-merge The PR is ready to go, and it will be merged soon if there is no negative feedback labels Oct 15, 2024
Copy link
Member

@basil basil left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new behavior has required a number of tests in core to be updated, so it is likely additional tests will need to be updated (ATH and/or plugins). Please run tests in jenkinsci/bom and jenkinsci/acceptance-test-harness with these bits to confirm no additional tests need adjustment.

I am also asking for security review of this PR, as it changes the expected behavior of a number of tests for past security fixes. The new expected behavior looks good to me, but I wanted the security team to confirm.

@basil basil added the needs-security-review Awaiting review by a security team member label Oct 15, 2024
@basil basil requested a review from a team October 15, 2024 16:26
@@ -685,7 +685,7 @@ public void symlink_outsideWorkspace_areNotAllowed() throws Exception {
assertThat(zipPage.getWebResponse().getStatusCode(), equalTo(HttpURLConnection.HTTP_OK));

List<String> entryNames = getListOfEntriesInDownloadedZip((UnexpectedPage) zipPage);
assertThat(entryNames, containsInAnyOrder(
assertThat(entryNames, hasItems(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As in commit 14cf0bf, please strengthen the assertion by maintaining the original containsInAnyOrder and adding any newly expected entries to the test.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will do today!

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@basil my latest commit should've fixed that. Could you double check?

@DerSimeon DerSimeon requested a review from basil October 15, 2024 19:22
Copy link
Member

@basil basil left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code looks good to me. From my perspective, this PR is now ready for ATH/PCT testing and security review.

@@ -987,7 +993,7 @@ public void directSymlink_forTestingZip() throws Exception {
assertThat(zipPage.getWebResponse().getStatusCode(), equalTo(HttpURLConnection.HTTP_OK));

List<String> entryNames = getListOfEntriesInDownloadedZip((UnexpectedPage) zipPage);
assertThat(entryNames, hasSize(0));
assertThat(entryNames, hasSize(6));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should add a containsInAnyOrder assertion after this to match the expected 6 entries, like the others in this file.

@DerSimeon
Copy link
Author

DerSimeon commented Oct 15, 2024

The new behavior has required a number of tests in core to be updated, so it is likely additional tests will need to be updated (ATH and/or plugins). Please run tests in jenkinsci/bom and jenkinsci/acceptance-test-harness with these bits to confirm no additional tests need adjustment.

I am also asking for security review of this PR, as it changes the expected behavior of a number of tests for past security fixes. The new expected behavior looks good to me, but I wanted the security team to confirm.

Can you tell me how to run the ATH? do I just run mvn test in the test module?

@basil
Copy link
Member

basil commented Oct 15, 2024

@DerSimeon
Copy link
Author

DerSimeon commented Oct 15, 2024

so make a pull request and change the jenkins.version property if so, where do I get the value from?
Also once it passed all its test do I just close it and reference it here?

@basil
Copy link
Member

basil commented Oct 15, 2024

When #9836 (comment) has been addressed and you have a passing CI build, the Checks tab will provide a section with the incremental build version number, which you can then consume in jenkinsci/bom and jenkinsci/acceptance-test-harness.

daniel-beck

This comment was marked as outdated.

@DerSimeon
Copy link
Author

Archiving the artifacts ** of a freestyle job with the shell step

mkdir -p foo bar bar/one bar/two
touch baz bar/qux bar/two/f

results in the directory foo not being archived, only the other empty dirs. This seems unexpected. Why archive subdirectories but not top-level directories?

A bunch of names and labels become (at least technically) wrong with this change, like the collectFiles method in this PR, or (download all files) and the help text of the "Archive the artifacts" post-build step on the UI. Additionally, the "Archive the artifacts" post-build step links to Ant documentation for the pattern definition, and I think Ant only supports files? So that would also be inconsistent if confirmed.

JENKINS-49296's wording suggests adding an option, while this does it unconditionally. This be considered a major change, as it will affect users relying on the current behavior for archived artifacts.

What would be your proposal? So far nobody has mentioned that, and from my tests the stated behaviour could not be verified. I will retry later when I have more time.

@daniel-beck
Copy link
Member

Thanks for challenging me on this, I checked again and I am unable to reproduce the behavior 🤦 No clue what I did, or thought I saw.

@daniel-beck
Copy link
Member

daniel-beck commented Oct 16, 2024

However, I also don't see the intended behavior for JENKINS-49296, at least for the build-in "Archive the artifacts" freestyle post-build step: Downloading artifacts does not result in archives containing empty directories. Looking on the controller file system, empty directories are also not being archived there.

@DerSimeon
Copy link
Author

Maybe empty directories are being additionally filtered somewhere?

@daniel-beck
Copy link
Member

daniel-beck commented Oct 16, 2024

Maybe empty directories are being additionally filtered somewhere?

That would be my guess. I would appreciate if you could reproduce my findings independently first though, to ensure I didn't misinterpret something I was seeing again :)

If we don't have it yet (and didn't just fail for the above reason), the addition of a test going from CreateFileBuilder (or similar for dirs) to inspecting an artifact archive zip file, confirming contents, would be useful.

Copy link
Member

@daniel-beck daniel-beck left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Noting this doesn't seem to work as expected per #9836 (comment).

@DerSimeon
Copy link
Author

Hey @daniel-beck I am currently on vacation so it might take a bit for me to be able to investigate. If you can point me into the right direction and tell me where I have to implement I fix, I could do it on my laptop.

@daniel-beck
Copy link
Member

point me into the right direction and tell me where I have to implement I fix

No idea, sorry. Would need to step through it to see what's wrong.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug For changelog: Minor bug. Will be listed after features needs-ath-build Needs to run through the full acceptance-test-harness suite needs-security-review Awaiting review by a security team member
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants