When I want to download an artifact I use the following kind of URL: https://github.com/some_user/some_repo/suites/some_id/artifacts/some_id. This however always leads me to a .zip package even if the result is just a single file. In my case this additional layer is totally redundant and I'd like to skip it (it's especially annoying when I build a pdf that I want to be able to preview conveniently).
(How) can I setup the automated workflow to expose unpacked files?
It's not possible at the moment:
Note: We only currently support downloading an artifact from the GitHub UI by zipping all the files together (this is independent of how the artifact gets uploaded). If you upload an individual file, in the UI the artifact will still present itself as a Zip because that is currently only what we support. We have plans in our roadmap to offer a more enhanced artifact UI experience that will allow you to browse and download individual files from an artifact. No ETA on when that might arrive, but it is something that we really really want to enhance.
https://github.com/actions/upload-artifact/issues/3#issuecomment-598820814
This is a limitation of our APIs and our UI, some of my earlier comments go into more details #39 (comment) and #39 (comment)
If you also look at our public api to download an artifact, you'll notice that we currently require a zip :archive_format: https://developer.github.com/v3/actions/artifacts/#download-an-artifact and that is what effectively is being used when you click to download an artifact. Ideally we should have options that let get the raw contents of whatever was uploaded without any archiving format, but we currently don't have any solutions disappointed
https://github.com/actions/upload-artifact/issues/109#issuecomment-671853296
Related
I found a small GitHub project that I want to use (https://github.com/NewSignature/us-map) to create a clickable map. It is a jQuery plugin. I don't want to download it and clutter up my project though. Is there a way to link to the project in like a script tag and link tag?
It is possible you could use a CDN for this if the project offers one already. You could ask the project if one exists, or see if common CDNs already offer it, and use that. Otherwise, you'll need to host it yourself.
While GitHub does provide a way to view the raw contents of a file, it isn't intended as a CDN for you to use. Raw files are not hosted directly, but instead generated from the repository, so for performance and availability reasons, GitHub doesn't want people to use it as a substitute for hosting their own dependencies.
I'm evaluating GitHub as a way to keep under version control and share some excel files containing basically financial models.
The issue I'm facing is this one: I need to share the Release artifacts (a bunch of xlsx files) with people outside GitHub, so I'd like to include the version number in the filename to be sure that, even when the files will be further shared by business people through email or other non-GitHub means, that information won't be lost.
Is there a way to rename the artifacts automatically? GitHub Actions seemed to be the right way to address this thing, but unfortunately they're still unavailable on the Enterprise Server my company is using (v 2.19.13, I don't have any administrative access to it, btw), and adding some CI toolchain just to rename some files is probably too much.
Thank you in advance for any response!
Michele
When you create a Github Organisation or a Bitbucket Team/Project, one of the configuration items is:
Project Recognizers: Pipeline Jenkinsfile
There are no other options other than "Pipeline Jenkinsfile", however the fact that the option is even there suggests that the developers envisage people writing their own custom 'recognizers' for projects that don't have a single 'Jenkinsfile' in the top directory of the repo.
Can anyone point me in the direction of any other project recognisers that can be installed and used, or even some details on where to start to implement my own recogniser?
My particular use-case is that within a single repository, we define several workflows that orchestrate actions over code / configuration in the one repo, and I would love to be able to use the Bitbucket Team option to dynamically scan the repo, find all the *.Jenkinsfile files across all branches / pull requests and populate the necessary pipelines.
For example, in the repo are the files:
/pipelines/workflow1.Jenkinsfile
/workflow2.Jenkinsfile
/workflow3.Jenkinsfile
I would like jenkins to create the folder structure:
/team/repo/workflow1/master
/dev
/PR1
/workflow2/master
/dev
/feature-xyz
Any thoughts on where I could start with creating a Project Recognizer to do this (if this is even possible) ?
I think you can do that with providing several Project Recognizers with different names, for example:
Project Recognizers
=========================================
**Pipeline Jenkinsfile**
Script Path: pipeline/workflow1.Jenkinsfile (or path to the file that contains valide Pipeline steps.
=========================================
**Pipeline Jenkinsfile**
Script Path: pipeline/workflow2.Jenkinsfile (or path to the file that contains valide Pipeline steps.
=========================================
**Pipeline Jenkinsfile**
Script Path: pipeline/workflow3.Jenkinsfile (or path to the file that contains valide Pipeline steps.
Another option here, could be Pipeline Shared Groovy Libraries Plugin, more details about this plugin can be found at Extending with Shared Libraries.
This approach gives you ability to use your custom scripts (Classes, steps, etc.) which means that you can define your own flow depending on repo name, project name, etc.
As of now, there should at least be the option to provide an alternative recognizer for the Jenkinsfile. This was added in JENKINS-34561 - Allow to detect different Jenkinsfile filenames. You can see the pull request at jenkinsci/workflow-multibranch-plugin/pull/59 which may help provide some background information in how the recognizers work.
In terms of multiple being recognized from a single source, JENKINS-35415 - Multiple branch projects per repository with different recognizers and JENKINS-43749 - Support multiple Jenkinsfiles from the same repository are requests that are very similar to this one.
A comment from Stephen Connolly in JENKINS-43749 says this about it:
What this is asking for is, instead, to create a computed folder with a pipeline job for each jenkinsfile within the branch.
I think the APIs should support that if somebody wants to take a stab at it. The only issue I see is that we may need to tweak the branch-api to allow for the branch jobs to be a non-job type (i.e. computed folder)
It sounds like you will need to implement a BranchProjectFactory (example: WorkflowBranchProjectFactory) that is a factory for a ComputedFolder (example: WorkflowMultiBranchProject).
Good luck!
Is there a way to automatically generate a change log from Github issues?
Ideally I want to be able to point at a closed milestone and generate either a plain text list of closed issues with their titles or, even better, a list with markup for links to the issues and the title of the issues themselves.
You can try to use Github-Changelog-Generator. (I'm author of this project)
It generates changelog from tags and merged pull-requests.
This script also have a support of GitHub Issues.
This changelog was generated by this script. CHANGELOG.md
Example:
Changelog
1.2.5 (2015-01-15)
Full Changelog
Implemented enhancements:
Use milestone to specify in which version bug was fixed #22
Fixed bugs:
Error when trying to generate log for repo without tags #32
Merged pull requests:
PrettyPrint class is included using lowercase 'pp' #43 (schwing)
support enterprise github via command line options #42 (glenlovett)
This isn't for Github specifically, but through Git you can run the log through pretty print to generate a changelog style html page.
From https://coderwall.com/p/5cv5lg
git log v2.1.0...v2.1.1 --pretty=format:'<li> view commit • %s</li> ' --reverse | grep "#changelog"
You can use the GitHub API to get a list of issues associated with a given milestone.
For example:
curl https://api.github.com/repos/<user>/<project>/issues\?milestone\=1\&state\=closed
replace <user> and <project> with the username and project and this will return a json list of all closed issues of the milestone with the id 1. You can then, for example, use a script to extract the information you are interested. Here is a python example that prints the list of issues as restructured text:
import json
with open("issues.json") as of:
data = json.load(of)
for issue in data:
t = issue['title']
n = issue['number']
url = issue['html_url']
print "* %s [`Issue %s <%s>`_]" % (t, n, url)
See if the following tool will do for you github-changes.
Disclosure: I'm the author of the tool.
We created an open source project to generate changelog from the list of closed github issues since a given datetime. It's available here: https://github.com/piwik/github-changelog-generator
Not directly through GitHub: that would be a kind of hook that you could put in place, and which would based on naming convention or comment convention that your project might follow.
Even using the issues title isn't always a sure way to generate meaningful change log, unless you review and edit if needed each and every issue title of your project.
In other words, it is very dependent on how you manage your project and not easily generalized to all GitHub repos.
I said as much in a very similar question "Publish a project release (binary/source packages) on Github?".
In addition of a third-party solution (or a GitHub Action like generate-changelog), you might soon Q3 2021, have a native feature from GitHub:
One of the most important parts of the software lifecycle is releasing your code for others to consume.
GitHub Releases will make that even easier by providing compelling and automatic release notes.
When creating a Release, you can click a button to automatically generate release notes.
If you want something more custom, you can a REST API to get the generated release notes and integrate them into your existing releases process.
We also want to ensure that these release notes look amazing when a maintainer shares them and make them easier to discover. We have done a complete redesign of releases to make projects announcements look stunning.
We are surfacing these releases in the feed to increase discovery.
We are also improving the open graph data for releases so they look equally fantastic when shared off of the GitHub platform.
Intended Outcome
Our number one goal is to make it easy for maintainers to create great release notes so more people can discover that amazing work maintainers are doing.
With minimal effort many projects will be able to benefit from detailed release notes.
For maintainers who put more time into their release notes to write editorialized content the intended outcome is that we free up time they are currently spending to maintain custom infrastructure and compile a changelog so they can focus on the most important content for their customers, high quality editorialized content.
Our other goal is to ensure that the release notes look great and are something maintainers and developers are excited to read and share.
How will it work?
The new Releases UI will be able to be enable with feature preview
A new button in the Release creation UI will be able to be pressed to generate release notes from any tag
The generated notes will be able to be configured via a .github/release.yml
A new REST API will allow customers to generate notes at their own convenience to further automate and customize the experience with GitHub actions.
I helped build a jQuery plugin for this recently that uses GitHub issues to communicate app updates directly to the user. The repo can be found here https://github.com/uberVU/github-changelog
Usage is pretty simple:
$(function() {
var $demoChangelog = $('.demo-changelog');
//call the plugin on a dom none
$demoChangelog.changelog({
//give it a repo to monitor
githubRepo: 'uberVU/github-changelog-playground',
});
//manually check for new closed issues
$('.demo-button').on('click', function(e) {
e.stopPropagation();
$demoChangelog.changelog('checkForUpdates');
});
});
I have an application and it is currently using one of the PullToRefresh libraries off of gitub. I've forked that repo, made some changes to better suit my app. I am responsible to give my customer the code for my application, so this would include the library. What is the recommended way to include it with my application source code (Using SVN for the android app itself).
I imagine at this point, you've long resolved your particular issue. For future generations, then:
If you're handing the user a zip with a snapshot of the source, include the library source in a subdirectory. What I have also done to good effect is to build a release bundle archive, which contains all of the different bits needed both binaries and sources.
If you're handing over source code repositories, again you can zip up each repository into a bundle you can hand over. It's probably worthwhile documenting the upstream for each bit of the project, so the customer can update your fork if they need to.