On GitHub there is a raw button that allows you to download the raw contents of a file.
The raw URL is for that particular version of the file.
Is it possible to get a raw URL that always downloads the latest version of a file?
It's possible to specify a branch name instead of an object ID in the URL. For example, to always get the version of Git's README that's on the master branch, you can use https://raw.githubusercontent.com/git/git/master/README.md.
However, be aware that, like all accesses to raw.githubusercontent.com, there is caching involved and that can't be disabled, so while the URL will eventually be updated, it may not be immediately. If you need the absolute latest version of a file at all times, or if you need that file for an automated process (such as another website or a program), then you need to host it yourself.
Related
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.
In Azure DevOps :
We have a build pipeline, configured through the GUI editor.
I would like to share a link with my colleagues which points to a precise revision of this build pipeline
("sharing with my colleagues" = mention it in our internal issue tracker)
Question
Is there a way (through devop's GUI) to view the state of a build pipeline at a given revision?
A way with a shareable url?
I don't think you can show a precise revision of a build definition in the UI without to revert to this revision. you can see a revision of the build in a JSON format. if you go to "History" Tab and compare the difference between versions:
You will get a screen with the current version and the other (in JSON).
The URL in the comparison page is also unique to this comparison so you can share it.
Another option is to use the Rest API to get the precise revision, but also only in JSON format:
https://dev.azure.com/shaykia/{project-GUID}/_apis/build/Definitions/{build-id}?revision={revision-id}
The above call returns a JSON of specific revision, you can also share it.
(You can get all the revisions with Get Definition Revisions API).
I downloaded the latest version of leaflet (1.3.1) from leafletjs.com and noticed that it differs from unpkg.com: https://unpkg.com/leaflet#1.3.1/dist/leaflet.js
The second line of leaflet.js is:
unpkg.com:
* Leaflet 1.3.1, a JS library for interactive maps. http://leafletjs.com
zip file from leafletjs.com:
* Leaflet 1.3.1+Detached: ba6f97fff8647e724e4dfe66d2ed7da11f908989.ba6f97f, a JS library for interactive maps. http://leafletjs.com
Why is that? I modified one of the leafletjs.com examples to use a local copy of leaflet which I just downloaded. It didn't work because the link integrity failed, so I found out that the files are different. Shouldn't they be identical?
I cloned the git repository and check-out tag v1.3.1. The commit checksum is the same as the one that appears in the zip file: ba6f97fff8647e724e4dfe66d2ed7da11f908989
That is strange, there is probably a bug in the release process that makes the download zip file contain a slightly different version from what is published on npm / unpkg.
Yes you are right, these files are supposed to be identical.
As a workaround, you can simply locally save the version that you get from unpkg.com CDN.
The files in the v1.3.1 tag are correct, you can also use those.
As for the SRI check, it is interesting when you use files hosted somewhere else outside your control, like a CDN. In case that external host is compromised and files are infected, the SRI check will reject them, keeping your visitors safe.
In case you use locally hosted files, i.e. in the same server as your HTML page, SRI is much less interesting: if an attacker can access your server and infect your files, he/she can simply infest your HTML page and modify any SRI hash, or just anything anyway.
As for why the file in the zip does not pass the SRI but mentions the same commit hash as the tag release, it is simply a matter of environmental setting when building the file. Both versions were built from the same commit. But the file in the zip probably was built without the "release" flag, making its introductory print slightly different (it mentions the commit hash instead of just the tag name), hence its SRI hash is different, even though the code content is the same.
I’m trying to use the Dropbox API to create a copy of an older revision of a file.
The use case is that the user browses his files, picks one and lists its revisions, picks one of the revisions and copies it to some folder in his account.
However, as far as I can tell, the copy method in the API only accepts a source path and there’s no way to specify a revision. I tried passing a revision in the path as is supported in download, but that fails.
Therefore, I could only think of the following workarounds:
Use restore to rollback the source file to the desired revision, copy it to the destination folder , and restore it back to the original revision
Download the desired revision and upload it to the destination folder
I don’t like solution #1 because if something goes wrong during the process, the user may end up with an older revision of the original file. Solution #2 does a redundant download and upload.
Can anyone suggest a better way to implement this functionality?
I just started using github.com and my friend and I are working on a project. How can I pull parts of the project but check out certain files I'm working on so he doesn't work on them. He can still download the files but he won't be able to open or edit them until I upload them back and give permission?
I suppose you mean lock a file when you edit it. Git won't let you do this and it's not something you need to worry about. Instead, you can both work on the same file and then merge your changes later.
If you really want to work that way (i.e: lock files, or at least control when your friend will modify your repo), you can ask your friend to fork your repo.
That way, he/she:
will have his/her own copy of said repo
will work on any file
will rebase first with branches fetched from your repo (added as a remote on his/her fork, as described in GitHub: working with remotes)
will make pull request, allowing to decide what to include and when.
Historically version control systems provide a checkin/checkout feature. When you do a checkout, you reserve the artifact. If another person also has the same file checked out, then you get an error when trying to checkin the artifact. Not sure creating another fork is really the equivale