I want to check number of downloads for asset i have deleted. I can get release assets using API : GET /repos/:owner/:repo/releases/:id/assets, but this call doesn't list deleted assets.
Documentation doesn't mention any filters that might help me
Is there a way to list deleted assess via github API?
You can check with GitHub support, but I suspect the deletion of a release or an asset within a release is not something which can be undone or restored.
That means the asset deleted is not "kept" somewhere, and its associated statistics are not kept.
GitHub support confirmed, that it's not possible at this moment. And it seems like it won't be available anytime soon...
Related
GitHub has a public api that one can access to get current release info, and find the release file (.deb or .tar.gz or .exe, etc) by going to https://api.github.com/repos/[project creator]/[project]/releases/latest
Does GitLab have something similar? I'm working on an automated installer to get certain programs from GitLab that have releases. Using the above api for GitHub, I'm able to get the json info for the current release, and get the url to download the latest release, based on what version I want.
I'm hoping to find something similar in GitLab.
Look no further than GitLab's Release API Docs to start that investigation. It looks quite robust, and I believe you will find it can provide that information.
You can use this API to query for each project, looking for the releases it has. (You could also look for the availability of the project if you are unsure if it is present). Once found, determine the release to retrieve. It's important to note that releases are not always made by a team, so they hopefully are specifically packaging the code into a release for distribution. Additionally, via the API, you can also ensure that the release has specific tags so that if they are using tags, you can focus on specific ones of note, or you can use a more generic approach (e.g. semantic version) to determine which release to retrieve.
Hope that helps. GitLab has a rich API. Take a look.
I have quite a lot of 'hardcoded' pieces of information in the README of my Github repo.
The user name : instead of my username, can I put something like $USER (whatever the syntax is) ? I have some links, badges, that contain the user name. That causes issues when doing forks and then the same issue the other way around when doing pull requests.
The latest release : instead of hardcoding the latest release number in the readme, is it possible to use an existing variable ? In my particular case, I want to put a link to the latest release available on jitpack.io. It looks like https://jitpack.io/com/github/somebody/somerepo/something/2.0/something-2.0.zip
There are no variables in a README. A README is just a normal Markdown (or AsciiDoc, etc.) document that happens to be rendered on the main page of the repository instead of requiring that the user browse to it directly.
It may be that for the jitpack.io URL, there's a special latest version URL that you can use, but you'd have to check their documentation. I'm not personally aware of one. You could of course host a server that performs the correct redirects to your badges and release assets automatically (or proxies them), but there's no way to modify the README to make it anything other than a static document.
I see people hosting files (usually binary files) under https://github.com/downloads/<user>/<repository>/. How do they do it?
You can't. That doesn't exist anymore... GitHub used to have a Downloads API that was replaced by the Releases API back in 2013. Old links were redirected and still work as you can see on the example you provided in the comments.
Nowadays, if you want to make files available for download, you should use either the Releases feature or the Packages feature.
Currently, I am trying to do a user audit to remove old accounts from our environment. I found this KB about removing users from Azure Devops. I could not find any information about what happens to the content they uploaded if they get removed. If I remove a user from the organization, will the code or any content they have uploaded be removed as well?
Does removing a user from Azure Devops remove the content they uploaded?
The answer is no.
The code or any content they have uploaded will be control by the source control git/TFVC. The source control tool only track the files changes and record the history of changes. But the users is not within the scope of the source control, it only record the uses name who make any change in the source control.
Besides, if remove a user from the organization will remove the code or any content they have uploaded, which will cause all code development will be aborted due to developer changes. This will be a disaster. And, according to that document, it indirect explain that:
After you remove a user from Azure AD, you can't assign artifacts to
that user anymore. Examples are work items and pull requests. However,
we preserve the history of artifacts that were already assigned to the
user.
So, do not worry about deleting users from your organization will delete the code or any content they upload.
Hope this helps.
No. It would be totally useless as a source control or work tracking tool if data was abruptly removed because a user was removed.
After a release pipeline is deleted, is there a way to undo that deletion? One of our critical pipelines was deleted and while we had backed up the definition, it would be nice to know if Azure DevOps has the undo functionality built in.
Unfortunately, this is not supported at this time.
See this existing similar thread (Can I Recover A Deleted Release Definition?)
As a workaround, you can export your release pipeline definition just for the safety.
I just tried it on my private collection, this is not supported. Sadly there is no recycle bin similar to the work items bin from which you could restore the deleted definition. As a workaround for the future, what you can do is to regularly export all the definitions as json (click breadcrumbs, then export, this can also easily be automated via the rest api) and save them somewhere (e.g. in source control). That way you at least always have sth at hand, even if slightly outdated.