I have my own PHP/Composer repo on GitHub and have it published on packagist.org. Everything is fine so far. The Webservice is correctly configured and several versions have already been published.
But now I have the problem that when I try to publish a new version, it does not "end up" on packagist. Interestingly, packagist shows me (among older versions/tags) a version/tag "dev-master". After I pushed my latest changes to GitHub, created a tag/release on GitHub, and used "update" on the Packagist interface, this "dev-master" points to the latest commit on GitHub, but the new tag does not show up. Hence, when using ./composer update in a project, nothing is updated at all.
Here is step-by-step what I do:
Update and test my code.
push it to the master branch of the repo at GitHub (master is the only branch here a.t.m.)
update composer.json's "version" attribute to reflect the tag I am going to use for the next release
create a new tag via the "draft new release" function in github (e.g. "5.6.7")
go to packagist and click "update" in the repo.
Funny thing is, sometimes it works, sometimes not.
PS: Seems NOT to be an issue of delay. WHEN it worked, the new version was visible and installable within seconds. Otherwise, also waiting for several hours didnt fix the problem. Also, the hash of the latest commit from github is visible for "dev-master" immediately after I use "update" in Packagist.
Can anyone please tell be what I am doing wrong here?
Related
How do I go to a previous commit from GitHub Desktop? I did some work in my class yesterday and today when I pulled it said I needed to resolve merges, so I clicked continue from Main. Now I do not have the version in my unity, but I do have it in History. I would like to go back to that version.
I do not have the command line, please only options on GUI version.
I do not want to try anything without asking because last time it caused a lot of errors and corruption in my previous project.
Create branch from commit is probably your best bet. It will ask you to enter a name for the new branch. Once your done you can use the branch tab to switch back to your development branch.
I recently created an extension and I am trying to set up a workflow to automatically publish the extension to the VSCode marketplace when I see fit.
I have read the official article which only shows fractions of the final set up and which also seems a little outdated. Following that and copying from misc. repos on Github, I have patched together a semi-working solution. Yet, the workflow is really odd.
It seems like the tutorial is suggesting you try to run a vsce publish when a new tag has been pushed or a release has been created/published. But here is what that looks like:
Make a commit(s) with new code/features you want to add to the extension.
Change package.json manually to update the version number.
Tag the commit manually with the same version number.
Push commit and tag.
(make a release manually on Github to have consistency between tags and published extension version and to trigger eventual action)
Github action is executed and hopefully succeeds, otherwise you will have to redo a bunch of above steps.
The above workflow is not optimal as it requires you to enter the version number about 3-4 times. This can be improved somewhat.
Make a commit(s) with new code/features you want to add to the extension.
Run vsce package <version> to create a new commit with a new tag and also update package.json in one command.
Push commit and tag.
(make a release manually on Github to have consistency between tags and published extension version)
Github action executed vsce publish which almost certain to succeed since vsce package <version> already succeeded previously.
This scenario is better but still has some problems:
The Github Action will need to listen to a new tag push.
Could it also create a release automatically?
Is it common practice to always create a Github release from a tag?
Step 2 requires you to build the project to a .vsix file.
Can this be prevented?
We could instead do this on Github through and action. But what would we listen to to trigger this action? We need a version number, but it can not come from a tag since vsce package <version> creates a new tag and updated the pacakge.json for us.
What is the optimal workflow to make this process as painless as possible?
I had 2 repos on Github: "RepoName" and "RepoName_old". I thought I was going to rebuild my project but changed my mind and have been improving "RepoName_old" ever since. I deleted "RepoName".
If I rename "RepoName_old" to "RepoName" (the deleted repository), will something go horribly wrong? The official documentation warns against trying to pull from a branch associated with the old name...I guess that's a different thing...will GitHub Desktop acknowledge the new name after I make the change?
I have terrible experience mismanaging my git repositories and I want to avoid another setback by being informed and careful.
GitHub Desktop is a local tool which should reflect the changes done on GitHub.
On GitHub side, if you have deleted RemoName, you should be able to rename "RepoName_old" to RepoName.
Check first that it works on github.com.
Then try and clone it in command line, and, with GitHub Desktop, add it from your local folder. That should force GitHub Desktop to recognize RepoName with its new origin URL.
Because we've done some rearranging of our documentation setup, I have two separate read the docs projects which I need to build from the same GitHub repo. One of them is brand new, and the other used to be pointed to the old repo.
I have set up a webhook on each project, and added both these webhooks to the repo.
The problem is that in the project that used to be pointed to the old repo, the stable build is still associated with the SHA of the latest release on the old repo, which does not exist in the new repo. This causes the stable build to fail.
One other thing I hope to solve, when activating some of the new versions (which used to exist in the old repo) an "_a" is added to then of the published version name, even though there are not multiple publishable versions with the same name.
I'm wondering: is it possible to completely refresh all of the RTD-detected versions and tags? I think doing so would solve both these issues.
I've tried "wiping" the builds but that doesn't help, I have read the RTD docs on versions many times, and I've triggered new push events from github (which are sent and received successfully) but still can't make any progress.
The best way to solve this turned out to be just recreating the RTD projects. If anyone else comes across this issue, you could check out the ticket I made on the RTD repo https://github.com/rtfd/readthedocs.org/issues/3763.
Trigger a Build on any of the existing versions that RTD knows about. After that build job starts the Versions list will be updated from the git repo.
I created an Angular project using angular-cli and pushed it to GitHub. I then created a new branch and updated packages, installed standard-version and ran npm run release -- --first-release as instructed. I then pushed the whole into a new branch on GitHub, created a pull request, squashed and merged onto master, pulled back into local master, and ran standard-version again finally followed by git push --follow-tags origin master. Here's the state on GitHub:
All notes that I wrote in the pull request body are not visible in the changelog file, and they are obviously not in the chore(release) generated by standard-version. Why?
They are also not written within the Releases tabs at all, even though I can see the released tags there.
Should I have made the version 1.0.0 in packages.json before starting in order to adhere to semantic versioning?
What am I doing wrong?
You're not doing anything wrong. chore doesn't show up in CHANGELOG.md (see: https://github.com/conventional-changelog/standard-version/issues/135)
To have release notes uploaded, you will to use something like https://github.com/conventional-changelog/conventional-github-releaser
It's up to you where to start. Generally, when labeled 0.x, the project is still unstable and will go through vast API changes. When the project becomes stable, bump the major to 1.x and adhere to semver.