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

Bug: fatal: not a git repository when no .gitattributes file is present #32

Open
jakubmikita opened this issue Apr 1, 2020 · 12 comments
Labels
type:bug Something isn't working.

Comments

@jakubmikita
Copy link

Describe the bug
When there are no .gitattributes nor .distignore files present in the build, the action fails.

Please see the action log.

Steps to Reproduce
I'm using a build process that already puts all the clean files into a separate directory and starts the WP.org release from there. So I have only the files which need to be picked up.

Expected behavior
It just passes with all the files.

@jakubmikita jakubmikita added the type:bug Something isn't working. label Apr 1, 2020
@jakubmikita
Copy link
Author

Dirty fix - add empty .distignore file to the built files.

@helen
Copy link
Collaborator

helen commented Apr 1, 2020

Can you please describe the overall workflow you're looking for here? I think I understand it from looking but I'd rather you tell me than have me making guesses :) It is on my mind to add an example workflow to attach proper ZIP files to the GH releases as well, I just haven't gotten into what kind of changes or additions might need to be made to support that.

@jakubmikita
Copy link
Author

Sure @helen!

So my process looks like this:

  • Checkout the files and build everything (composer & yarn)
  • Copy the dist files to another directory
  • Upload this directory as an artifact
  • Zip this directory with a nice name and upload as an artifact

So this is the build process the rest of the workflow jobs are depending on. This way the plugin is built once, not in every job.

So then each action looks like this:

  • Create GitHub release: download the zip artifact and upload to the new GH release
  • Upload to my FTP: download the zip artifact and upload to FTP
  • Push to wordpress.org: download the build artifact and just push to SVN

Your action is failing because it needs either .gitattributes or .distignore file, even if all the files in the workspace are meant to be pushed to SVN.

I hope it clears the things out!

@jakubmikita
Copy link
Author

Because there's no git checkout, it fails here: https://github.com/10up/action-wordpress-plugin-deploy/blob/develop/entrypoint.sh#L82

@helen
Copy link
Collaborator

helen commented Apr 1, 2020

Yes, I can see the technical reason why this would fail, it began with git archive so I left that in place as a default via fallthrough rather than introducing another config option. The reason I'm asking for your workflow as a whole is because I don't believe in coming up with solutions until we've fully examined the problem :)

For the moment, I'm curious about .build-excludes - does it need to be named that way? It looks functionally the same as a .distignore to me (please let me know if I've missed a detail in there) so I'm curious if renaming it as such would fix the issue, at least to make this immediately usable even if it's not your ideal scenario.

There is a related issue in #30 where people are building into directories and want to deploy from there, so I think from a technical perspective these should probably be solved together.

@jakubmikita
Copy link
Author

jakubmikita commented Apr 1, 2020

I think it could be named .distignore instead of .build-excludes, that would make thing easier.

What won't work is the assets directory, I think I have to checkout git either way and fire up the build once again or pull the .wordpress-org directory somehow

EDIT: ended up with this workflow and we'll see

@helen
Copy link
Collaborator

helen commented Apr 1, 2020

What won't work is the assets directory, I think I have to checkout git either way and fire up the build once again or pull the .wordpress-org directory somehow

I think I might be missing something here - the very first step in your stable workflow is a checkout. I think what renaming that file would mean is that you would run this action from the checkout directory rather than the build one, and actually I am not sure I entirely understand how this is running out of the build directory in the first place? Or if it even is? People in #30 would probably like to know.

In my simplified view, this is what I think would work assuming you renamed .build-ignore as .distignore in your repo or copy it over during the course of the workflow.

  • Checkout
  • Run the replacers
  • Create a ZIP file using the ignore file (I think tar can handle this, or else I can think of some wackier ways to do it with Bash, or maybe there's an action to do this already) and upload it as an artifact. Question here: do you need the unzipped directory as an artifact? Again, very possible I'm missing some nuance just reading through a YAML file.
  • Deploy to .org using the same ignore file
  • Do your GitHub release with the ZIP artifact
  • Done?

@ottok
Copy link

ottok commented Apr 5, 2020

I seem to have bumped into the same bug. The line git add .gitattributes && git commit -m "Add .gitattributes file" fails with:

+ git add .gitattributes
fatal: not a git repository (or any parent up to mount point /github)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
+ git archive HEAD
+ tar x --directory=/github/archivetmp
fatal: not a git repository (or any parent up to mount point /github)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors

(extra lines due to debugging with set -x)

The funny thing is that this code is identical in the deploy and asset update actions. For the same repository, only the deploy fails (and asset update action succeeds). Could it be that Github Actions do something special about tag pushes, leaves .git away or?

@helen
Copy link
Collaborator

helen commented Apr 6, 2020

@ottok You're missing the line - uses: actions/checkout@master in your tag deploy workflow :) Without that, it will not have any of the contents you're expecting, and it will not be a Git checkout. Also, is there any reason that you're using a fork of the Action or were you just testing?

@ottok
Copy link

ottok commented Apr 6, 2020 via email

@ottok
Copy link

ottok commented Apr 6, 2020

Confirm: I saw this bug because the line - uses: actions/checkout@master was accidentally omitted. So user error.

Maybe @Kubitomakita's problem in https://github.com/BracketSpace/Notification-Signature/blob/2111b3057efe3120f4a7e4dc249ec853e8e443d5/.github/workflows/stable.yml#L97-L113 is that he is using artifacts built from the repo, and not the git repo itself?

@jakubmikita
Copy link
Author

jakubmikita commented Apr 6, 2020

It is indeed. I ended having a classic workflow, with git checkout, build and this action and it's working fine. See: https://github.com/BracketSpace/Notification/runs/563654808?check_suite_focus=true

But still would be good to get it working with artifact

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:bug Something isn't working.
Projects
None yet
Development

No branches or pull requests

4 participants