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

Feature request: wildcards #11

Closed
StoneCypher opened this issue Sep 9, 2019 · 22 comments
Closed

Feature request: wildcards #11

StoneCypher opened this issue Sep 9, 2019 · 22 comments
Assignees
Labels
v2-preview Available or fixed in the v2-preview
Milestone

Comments

@StoneCypher
Copy link
Contributor

One of the really useful things about uploading artifacts is caching logs, coverage reports, et cetera. Those often have timestamps or UUIDs as names.

You can hack around it with a compression to a known name step, but, uploading and downloading artifacts by wildcard (or even just download-all) would be a huge benefit

@eine
Copy link

eine commented Sep 10, 2019

Possible duplicate of #3.

@StoneCypher
Copy link
Contributor Author

Thanks, no, my request is just for wildcards. The thing you asked for is nice, but way more work

@StoneCypher
Copy link
Contributor Author

Please stop trying to take over my issue. :(

@yacaovsnc
Copy link
Contributor

yacaovsnc commented Nov 27, 2019

@StoneCypher thanks for the feedback!

I understand the uploading part, could you please help clarify on the download all request a bit more?

Say we have this file structure:

.
├── aa.txt
├── ab.txt
├── ba.txt
└── folder1
    └── ac.txt

and we use wildcard in path to upload **/a*.txt with a name of my-artifact, that artifact should contain aa.txt, ab.txt, and folder1/ac.txt.

When you say download artifact by wildcard, do you mean download from the UI on github.com; or using the download-artifact action?

If using the action, we need to give the action the artifact name, in this case my-artifact, and it will download everything in this artifact. Will that work?

EDITED: fixed up the matching pattern, thanks @umarcor!

@umarcor
Copy link

umarcor commented Nov 28, 2019

@yacaovsnc, IMHO a*.txt should not include folder/ac.txt. In order to include aa.txt, ab.txt, and folder1/ac.txt, the param should be **/a*.txt or ['a*.txt', 'folder1/a*.txt']. Please, see #3 (comment).

@zegnus
Copy link

zegnus commented Nov 30, 2019

In an Android multi-project setup, static analysis and test results are generated under the individual projects, but with the same folder structure. Example:

.
├── module1
	└── build
		└── reports
			└── checkstyle
				└── main.xml
				└── main.html
			└── pmd
				└── main.html
				└── main.xml
			└── findbugs
				└── debug.xml
				└── debug.html
			lint-results.html
			lint-results.xml
├── module2
	└── build
		└── reports
			└── checkstyle
				└── main.xml
				└── main.html
			└── pmd
				└── main.html
				└── main.xml
			└── findbugs
				└── debug.xml
				└── debug.html
			lint-results.html
			lint-results.xml
...

It would be great if we can use a wildcard for the path in the form of:

  • **/build/reports/checkstyle/*.html
  • **/build/reports/pmd/*.html

Or if possible:

  • **/build/reports/**/*.html

Or even better, to archive all *.html files under build/reports folder and subfolders

@StoneCypher
Copy link
Contributor Author

So my big problem is coverage files.

I want to use artifacts as a way to join coverage from separate runs. This is reasonable because my coverage tool names the files with a timestamp and a uuid

Unfortunately, the only way I can indicate things is by filename, so first I need to zip up things to create a predictable file name, then undo that at the other end. Slows down the build fairly substantially (~20s on top of ~90s)

Globs would solve this

@yacaovsnc
Copy link
Contributor

@yacaovsnc, IMHO a*.txt should not include folder/ac.txt. In order to include aa.txt, ab.txt, and folder1/ac.txt, the param should be **/a*.txt or ['a*.txt', 'folder1/a*.txt']. Please, see #3 (comment).

Thanks for the correction! Yes, **/a*.txt or a list is the right syntax.

@yacaovsnc
Copy link
Contributor

@StoneCypher cool, I definitely understand the desire to upload by wildcards. We are designing the next version of this action and this is what we are considering:

  1. Upload by wildcards. The above examples shows the behavior.
  2. Download by wildcards are supported at the artifact name level. For example, I can have those two artifacts:
    i. my-artifact1 which includes aa.txt, ab.txt, and ac.txt.
    ii.my-artifact2 which includes ba.txt, bb.txt, and bc.txt.
    We support download my-artifact*, but not a*.txt, i.e. we will not look into each artifact to find out matching files.

Does that work?

@StoneCypher
Copy link
Contributor Author

I believe that that would work in a pinch, since i could indicate the contents of an entire directory, but the node standard (and surprisingly easy) thing to do would be to use a globber, nominally node-glob

Either way. I really appreciate the help

@StoneCypher
Copy link
Contributor Author

node-glob would also save you from ever having to deal with a whole bunch of long term bullshit like traversal attacks

@koppor
Copy link

koppor commented Dec 20, 2019

For a single file, following is a solution (based on #7 (comment))

      - id: getfilename
        run: echo "::set-output name=file::$(ls build/*fat.jar)"
      - uses: actions/upload-artifact@v1
        with:
          path: ${{ steps.getfilename.outputs.file }}

@solodon4
Copy link

solodon4 commented Jan 6, 2020

I believe upload artifacts should accept an array of path entries much like path triggers do. Positive wildcards then define the set of files to include for upload while negative patterns (those starting from !) exclude files from upload. Patterns should be evaluated in order given by the user to determine the final set of files.

@umarcor
Copy link

umarcor commented Jan 6, 2020

I believe upload artifacts should accept an array of path entries

See #3 (comment)

CagtayFabry added a commit to vhirtham/pythonTest that referenced this issue Jan 30, 2020
smaillet added a commit to smaillet/Llvm.NET that referenced this issue Feb 20, 2020
Due to a lack of [WildCard](actions/upload-artifact#11) support in the upload-artifact action the only way to get the files uploaded is to use a seperate folder for the logs. :(

Modified Push-Docs to actually push and to simply bail out under unsupported conditions.
smaillet added a commit to UbiquityDotNET/Llvm.NET that referenced this issue Feb 20, 2020
Due to a lack of [WildCard](actions/upload-artifact#11) support in the upload-artifact action the only way to get the files uploaded is to use a seperate folder for the logs. :(

Modified Push-Docs to actually push and to simply bail out under unsupported conditions.
@konradpabjan
Copy link
Collaborator

Wildcard support is now available with the v2-preview

see: #62

@konradpabjan konradpabjan added the v2-preview Available or fixed in the v2-preview label Mar 13, 2020
@StoneCypher
Copy link
Contributor Author

thank you @konradpabjan

@konradpabjan
Copy link
Collaborator

Going to keep this issue open for a little longer @StoneCypher until v2 is out of preview and this feature is officially out (should be 1-2 more weeks depending on how smooth v2-preview is coming along)

@xenoterracide
Copy link

tried this

        uses: actions/upload-artifact@v2-preview
        with:
          workdir: packages
          name: dist
          path: |
            */dist

expecting it to work like this (but obviously with a zip instead)

tar -cJf dist.tar.xz */dist

I see no artifact on my build

@xenoterracide
Copy link

oh, it's because upload doesn't support workdir, nevermind

@amccool
Copy link

amccool commented Apr 23, 2020

this preview is working for me (and rather necesary). Is there is a scheduled release date?

@konradpabjan
Copy link
Collaborator

Plan is to release v2 next week on the 28th. Small mention here: #62 (comment)

@konradpabjan
Copy link
Collaborator

v2 upload artifact has been released! https://github.blog/changelog/2020-04-28-github-actions-v2-artifact-actions/

You can now use the feature by using actions/upload-artifact@v2

For those that tested wildcards during the v2-preview thank you ❤

knocte added a commit to nblockchain/geewallet that referenced this issue Nov 2, 2021
This way we avoid hardcoding the version number in yet one more place.

See actions/upload-artifact#11 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
v2-preview Available or fixed in the v2-preview
Projects
None yet
Development

No branches or pull requests

10 participants