I made a composer package to make an archive by selecting files and folders. The public URL not showing readme content but is available in GitHub readme also I can see the readme content when I am logged in to packegist.org.
Package URL: https://packagist.org/packages/csesumonpro/phpzipmaker
GitHub URL: https://github.com/csesumonpro/phpzipmaker
How to solve this issue?
Related
I am Creating snippet extention of react-native for VS-code. In that I want to add some images into README.md file, which finally show images on marketplace inside description tab of my extention.
I have tried below things in README.md but it gives me error:
ERROR Couldn't detect the repository where this extension is published. The image '/images/SnippetDemo1.png' will be broken in README.md. GitHub/GitLab repositories will be automatically detected. Otherwise, please provide the repository URL in package.json or use the --baseContentUrl and --baseImagesUrl options.
I am using artifactory and have no issues with the npm solution. However, I have set up composer using the "Set Me Up" instructions, i.e. installed the ~/.composer/config.json & ~/.composer/auth.json files. I now get the following error when I try to perform a composer install:
$ dcomp install
Loading composer repositories with package information
[Composer\Downloader\TransportException]
The "https://myartifactory.jfrog.io/artifactory/api/composer/php-local/packages.json" file could not be downloaded (HTTP/1.1 404 Not Found)
install [--prefer-source] [--prefer-dist] ...
The user I have configured in auth.json is an admin user, and I've pushed a single package into the Artifactory. Additionally, I noticed the url contains plural packages.json as opposed to singular package.json, so I am assuming this is an issue with the artifactory configuration itself and not the package I've uploaded.
For Artifactory to index composer packages successfully you also need to make sure that each package has version specified.
There are 3 ways to achieve that:
Include the version attribute in the package composer.json file
Set a composer.version property on the package itself.
Use the version field when deploying it via the UI.
You can easily test it inside the UI by clicking on the archive you just uploaded, then go to the properties tab and add a property for example:
composer.version with value for example 1.0.0.
The issue in my case was as a couple commenters observed: the index wasn't being generated.
For me, the fix was a matter of using a .zip compressed file to upload composer packages instead of a .tar.gz. I can't tell you why a tarball won't work, especially considering Artifactory's documentation explicitly mentions tar.gz, but it would appear .zip is the way to go.
When you first create a PHP composer repository in Artifactory it will not have the repository index yet (package.json file). The index will be created only after you deploy your first package.
It is possible that Artifactory was unable to read the package metadata for the package you deployed. In such a case, assuming this is the only package in the repository, the index will not be calculated.
In order to verify this is the case:
Browse the php-local repository in the Artifactory UI
Check for the presence of a .composer/packages.json file (relative to the repository root). If it does not exist, it is an indication that Artifactory was unable to calculate the repository index
Select the package you deployed, and switch to the Composer Info tab
Check that you can see the correct package version. If you see "No version found" - there was an issue with getting the version (probably because it is not included in the composer.json file)
Look for an error similar to the following in the artifactory log file:
Failed to persist package metadata for 'php-local/my-package.zip'.
Unable to read the package version from the extracted composer.json
file
If this is the case, you can solve the issue by:
Add a property named composer.version to your composer package and set its value to be the correct package version. You can do it by selecting the package file from the UI, switching to the Properties tab and adding a new property
If this done correctly you should be able to see the correct version in the Composer Info tab and that the packages.json file is being generated
If all of this does not help and the packages.json file is still not generated, there is probably another error which prevents Artifactory from generating it.
Try re-generating the repository index by:
Going to the root of the repository in the Artifactory UI
Right click the root of the repository and choose "Recalculate Index"
The index should be generated in the background
If the index is still not generated search the artifactory log file for any relevant error messages
Finally, one more option to try is deploying a different composer package and seeing if it behaves the same.
I have seen an Include / Exclude Pattern on the Jfrog repository that does not match the <vendor>/<package> naming standard cause this issue. We were able to upload artifacts but they were excluded metadata endpoint.
The following endpoint returned a 404 response code for every package until the Include / Exclude Pattern was fixed.
https://<org>.jfrog.io/artifactory/api/composer/<repo>/p2/<vendor>/<package>.json
I am trying to build a simple blog with Github Pages and I have tested my changes locally with jekyll serve bundler. The problem is when I push my changes to GitHub, I see the following error:
Your SCSS file blog/styles.scss has an error on line 15: File to import not found or unreadable: variables. Load path: /hoosegow/.bundle/ruby/2.5.0/gems/jekyll-theme-primer-0.5.4/_sass.
I looked at _sass/_variables.scss file and I don't see any obvious issues.
Any pointers? Appreciate any help (FYI - I new to ruby and jekyll ecosystem)
I was able to find the cause of this issue. The problem was that all my blog files were under the blog/ directory in the repository and GitHub Pages does not use that as the source to publish the blog. It expects the source to be at the root of the repository. Once I moved all the files to the root of the repository, everything worked fine.
I'm trying to setup Jekyll on GitHub pages. Locally I have no build/execution warnings/errors, even when I use bundle exec jekyll serve --safe. But the import command fails on GitHub pages. The error I'm getting back is:
Your SCSS file css/main.scss has an error on line 49: File to import not found or unreadable: base
I have not changed the contents of main.scss:
// Import partials from `sass_dir` (defaults to `_sass`)
#import
"base",
"layout",
"syntax-highlighting"
;
Defining the sass_dir variable explicitly in _config.yml doesn't help. Is there a way to debug scss files locally? I have tried using the sass command but it doesn't seem to work with scss files.
I know that the problem is with the #import part because if I comment it and push the build on GitHub pages no longer fails -- but my blog is ugly :)
Note: I have already tried what's described in SCSS #import in Jekyll 2.1 but it didn't get me somewhere.
Ok, get it ! It was simple.
Github pages is running from your repository root : faif.github.io
as your _config.yml file is in /blog, it doesn't see it an takes default settings for everything. eg : path for scss import, is faif.github.io/_sass and result in an error, because your files are in faif.github.io/blog/_sass.
First option
Move _config.yml at the root and tweak sass, includes, ... variables. I don't think it's the best option, but it can certainly be done as nearly everything if configurable in jekyll 3.1.x (documentation).
Second option
Create a blog repository
Clone it
git checkout -b gh-pages because project repositories are published from gh-pages branch only
Copy your blog folder content in this repository
Remove your blog folder from faif.github.io repository
Change baseurl to /blog in _config.yml
Commit and push
And your done.
I have created a new version of my Joomla extension.
Manual upgrade via zip file or the directory works fine.
But the automatic upgrade (which used to work fine before), now gives an error 500 and the following error messages: "Unknown Archive type", "*Update path does not exist" and "Installation unexpectedly terminated: Update path does not exist".
I have no idea why those messages appear.
The update.xml references the correct zip files. Downloading it manually works just fine.
Joomla(/php/apache) has all rights on the folder containing the joomla installation.
After trying the automatic update, the tmp folder contains the downloaded zip archive with the latest extension version, interestingly without the .zip extension. Is the Joomla downloader not correctly naming the file and then failing upon finding that the file doesn't have a .zip extension?`Or what could it be?
Would be very thankful for any ideas...
Edit: My project is hosted on github, and github seems to automatically create a subfolder in the downloaded zip archive, named -.zip.
I'm using a link to the tagged github zip directly in my update.xml
I'm not sure if github always added this folder in the zip file, back when it still worked for me...
Might the Joomla problem have to do with the zip file containng such a folder, and not directly the extension stuff at root level? If so, anybody know if/how I can change github to not create that subfolder?
Right, just had a quick test of this.
I couldn't seem to find out how to automatically zip up a sub folder (there is a way but I need to do some more research/ask questions regarding this), however what you can do is the following:
Create a zip of your Repo
Open the zip, extract the folder you wish to be zipped then zip it
Create a new version and then drag your zip file into the upload box
Publish the release
Here is an example, have a look at the "Creating Releases" sections at the bottom:
https://github.com/blog/1547-release-your-software
Hope this helps
To answer my own question:
Yes, github seems to have recently changed their policy to create a root folder in the zip file, named as the repository the zip file is downloaded for (stupid, if you ask me, since the exact same information is encoded in the zip file name already anyway!).
Edit and Rewrite: It seems that either something changed in Joomla or that if you adhere to a naming convention - namely the root folder in the zip file having the exact extension name (or, I think and have to test, actually the same as the file name, without the version information), then the automatic update will work.
So as in my case, I have a Joomla package; the package is now in a repository pkg_mypkg. The zip file generated by github has the name pkg_mypkg-version.zip (e.g. pkg_myfancyext-1.0.9.zip), and contains a folder named pkg_mypkg. And inside the pkg_mypkg folder is a pkg_mypkg.xml file, the extension manifest. And this actually seems to be the configuration where automatic update works.