10up
Bug: fatal: not a git repository when no .gitattributes file is present
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.
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.
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!
Because there's no git checkout, it fails here: https://github.com/10up/action-wordpress-plugin-deploy/blob/develop/entrypoint.sh#L82
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.
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
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
tarcan 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?
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?
@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?
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?
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