I have a private GitHub repository A that builds a library via GitHub Actions and uploads the built library as artifact at the end of the build workflow. This repository including the built library has to stay private due to license reasons.
Another public repository B should now link against that library during its GitHub Actions based build workflow. I only know the usual upload-artifact and download-artifact actions that can be used to manage actions within a workflow, but this does not seem like a solution to my problem.
Is there any official way to achieve what I want, is there any trick that could be used to make it work or is this simply not possible? If so, do you have recommendations for an alternative approach?
I realized it would be a lot easier to access release assets of repository A instead of workflow artifacts. There are multiple ready-to-use actions that allow uploading releases from within a workflow run.
I created a private and a public test repository where the private repository has a single release with a simple text file asset and the public repository has a simple Actions workflow that fetches the asset from the private repo. It uses GitHub CLI with a command like gh release download --repo <my/private-repo> <tag>. You find the repository here.
Related
I was wondering if there is a way to search for keywords in the code through multiple code repositories at once? Preferably I would like to specify a subset of repositories i.e. only those with a marking or organization, and then for a given keyword it would return the matched line together with the source repository and file.
If not wrong, it is impossible inside Foundry, but...
I would suggest a workaround.
You could clone the repository locally in your machine and then, opening the synced folders using VS Code, use its search feature, that is able to go through different folders content.
Clone function is available inside each code-repo, and in order to proceed you will need both a git client and VS Code installed locally.
I think what I am looking to do is fairly simple - I just can't wrap my head around it.
I've got a repo in AzDo. This repo contains configuration files for firewalls. This is how we manage changes in these configurations.
I've got a simple build pipeline that copies the relevant files and creates an artifact.
I have a release pipeline that gets the files onto the on-prem machine in my Deployment Group. The files show up in c:\azagent\r1\_work\<artifact folder>.
As part of this pipeline I am looking to copy the files from c:\azagent\r1\_work\<artifact folder> to e:\shares\<artifact name>. This is the part that I cannot figure out how to make work.
What strategy could I use to put this together? I've looked into the documentation but it seems like this is somewhat of an edge case (not deploying an app or web site, etc). Ideally, I'd love to do this in a multi-stage YAML pipeline - but from what I've read, it appears as if these do not yet support Deployment Groups. So a classic pipeline is fine for now.
You can add a copy file task(Click the plus sign(+) on the agent job and search for copy files) in your release pipeline to copy the files to a different place on your local machine.
Then you can specify the source folder(ie. $(System.DefaultWorkingDirectory)), and the contents to copy and the target folder(ie. e:\shares\). In below example all contents in $(System.DefaultWorkingDirectory)(ie. C:\agent\_work\r1\a) will be copied to folder D:\Test\New folder
Please check the prefined variables for more information about its map to the local folders.
I'm new to GitHub's template repositories. We've created a template repo for our course's code labs. Let's say it's on GitHub under myorg/labX. The students are using GitHub Classroom, which clones the template repo for each student under myorg/labX-studentlogin. We've got actions to run some tests against their code using GitHub's own CI, and I want to include badges in the repo's README.md to see the test results at a glance. So I know that
![](https://github.com/myorg/labX/workflows/task1/badge.svg)
will include the badge, but this is the status of the template repo, not student repos. Is there a way to automate this so that when the students get their clone, it will contain a README with the URL that refers to the status of their own repo?
Turns out there is a simple solution, but only for GitHub's own Actions status badges. We've changed the image URL in our README.mds to relative.
The only minor thing is GitHub will insert /blob/<branch>/ into relative links when rendering the readmes.
For example, workflows/task1/badge.svg will become https://github.com/myorg/labX/blob/master/workflows/task1/badge.svg), which won't render. So we had to prepend '../../' to fool it.
TLDR: in repo's README.md, use
![](../../workflows/<workflowname>/badge.svg)
to get a badge for an Action status in this repo. This way, each student will get a badge referring to his own repo, not the template repo.
However, still looking for a way to use an external badge service like shields.io in a way relative to the repo.
I agree it would be a great feature to have.
It looks like at this point, GitHub Template Repositories do not support variable substitution, which is what would make it possible.
I see it is discussed briefly here:
Variable substitution for GitHub Template Repository Usage
Perhaps you should join the discussion and/or cast your Kudo.
I have a small open-source C++ project, hosted on Bitbucket using Mercurial.
Now, I am developing a new feature which adds a couple of new files and new build targets; otherwise it does not change the existing files.
I have opened a new branch, but after I pushed it to the main repo I was told that I cannot make the new feature open .. so I closed the repo and started looking for a solution. I have two questions:
What would have been a good approach for this situation? I need something that allows me to synchronize fixes made to the common code between the public and private repo. I do not mind having the private code only locally. I found two things:
using private stage for the new branch; but I don't know how to get fixes I make in the secret branch to the common files over to the open repo
using subrepos; this would need some code restructuring, but might be cleaner .. it just bothers me that this is marked as "feature of last resort" in the documentation.
How do I fix the situation where I have already pushed the closed code the the repo? Would it help to strip the branch and push, or do I need to delete the repo from Bitbucket and create a new one?
Since I am happy with having the private branch only locally, I have done the following:
I stripped the private branch from the bitbucket repo as well as my local copy of that repo.
In my copy of the private repo, I merged the changes from the public to to private branch and also then copied any common files changed in the private branch into the public one.
Then I marked the whole private branch as 'secret', to keep it local.
For future work, I plan to using hg merge for moving changes from the public to the private branch and hg graft for the reverse direction.
As far as I can see, this should work...
I am in the process of rebuilding a API documentation site for an open source project where we want to keep an archive of previous releases. I am wondering how I can configure Jekyll to generate the right hierarchy?
We have the following directory layout in our current /docs folder (which we would like to reuse in Jekyll somehow):
current/
v1/
v2/
v3/
Whenever we release a new version the current folder gets copied to a new folder (say v4). The contents of each folder is something like this:
introduction.md
testing.md
api-foo.md
api-bar.md
I'd like these to be available under the url domain.com/v3/testing/, domain.com/current/testing/, etc. I see that I could probably employ collections to do this, having one collection per version. To do this I see myself auto-updating the _config.yml as part of a build script (I made an example doing this here), but I am not sure how to progress from here, or if using collections for this is the wrong approach ...
This is too brief of an update to be of real quality, but thought I would mention that we solved this in the end in the Sinon project. Check out the repo at GitHub sinonjs/sinon and see the docs folder as well as the scripts called from package.json.
Feel free to improve on this answer by editing it and adding content and links.